Recently, I was reading an interview with Scott Kubie in which he was asked "is there a piece of professional or life advice you've gotten that has always stuck with you" and to which he responded "clean your tools". I was immediately reminded of all the times my father said something similar to me about the care and maintenance of tools.
Often, as a child, I wondered why we spent the time maintaining our tools when they were just going to get dirty or dulled the next time we used them. In the case of some tools, and how they were soiled, I could understand - steel and water result in rust that means a replacement will soon be needed - but unless it means they'll have to be replaced, why clean or sharpen them?
As I worked, I learned that it was difficult - and sometimes impossible - to hold onto a metal wrench covered in oil; I learned that it was difficult - and sometimes impossible - to cut with an unsharpened blade. Well maintained tools, on the other hand, did the job they were designed to do, often wonderfully well. As much as my child self may have hated to admit it, my dad was right. The simple truth is that clean tools work better.
What does this have to do with technology?
More and more the tools we have created to write, test, and manage code are far from clean. They may be have been updated frequently, with bells and whistles added. They've been converted from plain-old semantic HTML, cascading styles, and vanilla JavaScript to the most popular frameworks. But, like a blade that has been sharpened in the wrong direction, our tools have developed a false edge that is likely to break off, leaving our tools dull and useless.
It can't happen - it won't happen, you say? It already has.
If we look at the standard tools developers use - things like BitBucket and WordPress - we find that many of them have significant accessibility issues, often resulting in a failure to meet the WCAG at even A-level conformance, brought on by how they're built and maintained. The latest WordPress editor, called Gutenberg, has consistently had significant accessibility issues and has been called "a regression in terms of accessibility level", frustrating testers to such a degree many refused to even look at it again.
Good engineers notice and point out the ways in which we've failed. For example, in a very public announcement, Rian Rietveld resigned as leader of the WordPress accessibility team, citing several issues that led to her departure - but our industry, as with many others, often tries to shout them down or shut them out, whether they be leads on projects in major organizations like Rietvel or entrepreneurs writing about the "State of Accessibility in Dynamic Web Content".
Although it isn't lost on many familiar with accessibility and the state of our tools that most of the issues cited in the post "I have resigned as the WordPress accessibility team lead. Here is why." (by Rietveld) are associated with React, the poor accessibility in one of the web's most popular tools is an uncomfortable truth that few are willing to even acknowledge.
Although the problem is not isolated to React, the lack of React developers with accessibility experience and the difficulties with accessibility in React itself is a problem for more than just Gutenberg, and for more than just WordPress, which controls nearly one-third of the Internet - it's a problem for any organization that uses React, because it's a problem in the ecosystem.
We've been building with dirty tools, creating an ecosystem that has shifted away from POSH and CSS with unobtrusive JavaScript to one written in a JavaScript tool that has an architecture and uses design patterns designed without accessibility in mind. That practice - that ecosystem - has grown developers who need to be encouraged and inspired rather than simply educated, because they can't, or won't, see why the lack of accessibility is a problem. Some even respond to code that resolves accessibility issues created as a by-product of using this tool with something along the lines of "that's not the React way of writing code", which is only slightly better than the "blind people don't use the web" that I received (as a response to a question about accessibility) when interviewing a candidate for a "senior UI engineer" position.
Granted, this post has, perhaps somewhat unfairly, focused on React when the problem is greater than React. In truth, I could list any number of tools - frameworks, like React, - that are, or have become, a problem. React is a bigger target at the moment because it's so fashionable nearly every organization of any size uses it. Organizations have become convinced that engineers won't work without it - maybe they're right - and engineers insist on using it because without it they find it difficult to land a decent gig.
But...here's something we know - the simple truth is that clean tools work better. It will always be the case that plain-old semantic HTML and lightweight, cascading styles will out-perform and be more accessible than sites written fully in Angular or React. If you're interested in diversity, or if you believe, like Tim Berners-Lee, that "the power of the Web is in its universality" and that "access by everyone regardless of disability is an essential aspect", you should be pushing for clean tools that will get your product in front of the greatest diversity and the greatest number of users.
Happy coding (with clean tools).
No comments:
Post a Comment