It is possible to build accessible websites. We know because we have experimented with it and researched it. We have failed at it, and kept trying until we succeeded. We have tools, too. We have lists, we have articles, and we have manuals. However, there are a few things we don’t have, yet – some that we might not even have imagined. Perhaps if we spend a few moments considering what we do have, and identifying the gaps, we can make it easier to imagine what we want to have in the world of tomorrow.
Roughly, the modern developer accessibility toolkit looks something like this:
- valid, semantic HTML
- some type of automated accessibility checker for the obvious ones (axe-core, ember-a11y-testing, etc)
- keyboard-only support
- color contrast checkers (galore!)
- checklists for testers
Most front-end conferences now have accessibility talks in their schedules as a rule, rather than exception; finding a good accessibility speaker is no longer a difficult task. We’re even making strides on accessibility in single page applications (SPAs) – Ember, React, and Angular all have accessibility integrated into their documentation.
But somehow, accessibility still isn’t easy for designers and developers- at least not in the ways that we’ve come to expect. Some things are easy for us, like building an Ember app, thanks to its zero config setup, or how we don’t have to think about manually adding prefixes to CSS, thanks to things like PostCSS and Autoprefixer.
When it comes to digital accessibility, developers have a laundry list of things-that-are-hard:
- Which screen reader and browser combinations work well together? Why can’t I use Voice Over + Chrome? Why are they not all interchangeable?
- Automated testing only covers a small percentage of total accessibility success criteria, and manual QA testing is costly and time-consuming!
- The specification is very difficult to understand and very hard to consume as a giant wall-o-text!
- The ARIA Authoring Practices demonstrates how ARIA can be used, which doesn’t necessarily mean that every pattern should be used. Some patterns, though correctly using ARIA, lack proper support and require developers to either mitigate these gaps themselves, or find alternate patterns.
- How do we deal with focus management between custom components? It gets especially tricky within composable components (i.e., components that have been built separately and then used together as one).
and the list goes on.
The thing is, there are far too few engineers who focus specifically on creating tools that make digital accessibility easier for developers. It’s a bit of a recursive problem- digital accessibility is difficult to grok, so fewer engineers have the skills necessary to build the tooling, and therefore fewer tools exist.
It would seem as though digital accessibility has a developer tooling problem. Or, perhaps we could look at this a different way…perhaps this is an opportunity. We could make this easier for ourselves.
Practical Steps for Today
Since I find lists generally useful when I am taking stock of a problem, here is a list of three practical steps teams can take TODAY to make digital accessibility easier:
- Integrate accessibility requirements from the start of every bit of work. Working on a solution? Digital accessibility should be a hard requirement. Full stop. If the “solution” isn’t accessible, then you haven’t found the solution yet. Keep working on it- you’ll get there! Check out tools like Assistiv Labs, that might be able to help with cross-browser/platform testing.
- Train to be a master. No one can do this overnight. Integrate training for all parts of your organization- hire experts to come in and provide training. Look for reputable online courses. Start adding in accessibility audits to code reviews and even consider making it a facet of annual employee reviews for developers that create code for the front-end. Change can be hard, but change starts with each one of us, and happens with every decision we make along the way.
- Participate in the process. Submit your ideas and wants to The Web We Want project. File issues with browsers and frameworks, and make it clear that you want this from them. When you figure out that an ARIA authoring practice doesn’t work in your app, file an issue on GitHub.
Imagining the world of tomorrow
After the practical things to help us right now, though, we can turn our thoughts to the developer experience we imagine having in the future.
I recently started a project called ember-component-patterns, which is specifically for Ember.js users but could be expanded for all frameworks. While still in its infancy, the project aims to take accessibility development one step further, by showing patterns, anti-patterns, ideas for styling, semantic HTML and how to turn all of that into an Ember component. There are too many bridges yet to build between the islands of JavaScript developers, web developers, designers, and anyone else involved in building digital products. I think this project will, at its completion, do its part to build a bridge or two. And maybe inspire a few more along the way.
Another imagination- what about a command-line tool for developers to review their own sites in the same way a screen reader would? Think more like a text adventure game- only it’s a tool for making sure you haven’t inadvertently created a keyboard trap, or content that doesn’t get properly exposed because it lacks appropriate semantics. I like this idea because I think it could provide a bridge between users with assistive technology and JavaScript engineers who spend their time at the command line. Experiencing the frustrations of the user with assistive technology within the medium that the engineer is familiar with would be a new approach to helping software engineers become more aware of what their code needs to actually do from a technical perspective. Plus, I think this would be really fun to use.
Finally- how could we better signal the intent of a piece of code, or part of a website? After all, successful digital accessibility is the capability to express intent in a machine-readable way, so that a developer’s code can be interpreted properly by the assistive technology. I don’t think we have the tools past semantic HTML & ARIA right now, and I think some imagination and experimentation has an opportunity to thrive here. We can create custom components to do some very cool things, but we need a new way to describe the intent and purpose of them to assistive technology.
It could be amazing- we just have to decide
While it is probably more likely than not that accessibility may have to be forced on developers by browsers (and who knows what that solution would look like), I dearly hope that this is not the inevitable future of our industry. I hope that our tenacity and ingenuity, paired with our creativity and imagination, will lead us to a different place entirely. My hope is that we will be inspired to create the world we want to live in, create the tech that allows us to develop inclusive experiences in a way that is fun for us, and makes the digital world possible for those who need it.
The digital future is inclusive for all kinds of users- there is no changing this or stopping it. It has already been decided and it is already happening. Those on the forefront of the what some would call the last frontier in tech are already showing us the way. While we could just wait to see what legal regulations and tech giants hand to us, it doesn’t have to be that way. We can create the tools that we want to use, that are fun to use, and that take us to the next level of web development.
We can create the the tools of tomorrow that we really want. Let’s seize this opportunity and create something incredible.
