Originally posted on marcus.io.
With the start of the new year, it is a good opportunity to look into the accessibility of your web app. Here are 20 starting points to make your web app more inclusive in 2020.
- Covering the basics is 90% of the way of making your web app accessible! Yes, there are special accessibility problems that have to do with how web apps work, but it is valid to say: If you concentrate on the basics of building an inclusive web document you'll take care of the huge majority of web app accessibility problems. And, tackle them first: Because what's the use of sophisticated focus management on route transition for example, when non-visual users can't really find the main navigation in the first place?
- Use the power of CSS feature queries like prefers-reduced-motion, and additionally offer the setting to disable animations. For some people, animations on the web can not only be annoying but actually harmful (see A11yProject's "Understanding vestibular disorders"). Fortunately, these users can now enable a setting in their operating system that they opt out of potential seizure triggering animations, and us developers can detect this setting. But regardless of the OS's ability to submit a prefers-reduced-motion preference: Use the power of your web app's state to implement a setting like this (here's an example how you could do this in Vue.js). A good real-life example is the new twitter web app.
- Test your apps loading/interstitial states with screen readers. A frequent feature of a web-app is to load data asynchronously, e.g. from an internal or external API or database. This leads to loading states that you, I assume, convey visually with nicely animated progress bars. But I invite you to check your app, and especially these in-between states with a screen reader: Is it clear what happens or does the screen reader just stays silent for an indeterminate amount of time? If so, I'd suggest you inform yourself if ARIA live regions can help (read the "accessible notifications" pattern on Accessible App)
- Add axe core, pa11y-ci, tenon-cli or the like to your tooling/tests infrastructure. With most web app comes a complex tooling setup in order to a development server, build your app and run tests. While this makes web app development rather complex, it gives you the opportunity to write and run tests, especially for accessibility. Note: only about 20-30% of accessibility issues are testable automatically, and there are sometimes false negatives – but in overall, having accessibility-related test coverage does no harm, especially when it comes to educating other team members working on the same project.
- Make sure that your whole app, especially the custom elements, are keyboard accessible. Keyboard accessibility is crucial to inclusive interface design. Many developers are not aware of the multitude of possibilities and strategies people have to use websites – and in that regard, how important keyboard accessibility really is. When speaking about custom elements, and first, make sure that this particular form of input really cannot be solved with a native input element (since it offers extraordinary amounts of inbuilt accessibility features). If this isn't feasible, take a look into the WAI-ARIA Authoring Practices (but also read the next item of this list).
- Follow "accessibility people" of your framework. By circumstance, or by design (?), oftentimes people very involved in communities surface as "thought leaders", or at least "representatives" of certain sub-topics in your framework of choice. I bet there are people specialising in accessibility and worth following (e.g. on social media, or via their blog RSS-feed) in every framework. Do just that, keep up to date with your libraries' features that possibly could help everyone implementing accessibility with it.
- Check if infinite scroll could be solved more accessible. Infinite scrolling, or virtual scrolling, is both very common in apps (think of: Twitter's ever-changing, self-updating and never-ending timeline) but also a very common accessibility problem. And while role="feed" informs screen reader users of a widget's dynamic and updating nature, infinite feeds are still a problem for other groups, for example keyboard-only, switch device or speech recognition users. I recommend checking Raghavendra Satish Peri's article "Infinite Scrolling & Role=Feed Accessibility Issues" – and also his suggestion to solve most of the problems, and whether this is a good fit for your projects that have infinitely scrolling parts.
If your web app enables people to create content – check if you can help them make it more accessible. Now, this is a topic that can't be summarized in a paragraph, since features for content creating come in different shapes and sizes. But the important bits are: make sure that both user-generated content and the way to user-generated content is accessible. And that there is
an appa standard for that: The Authoring Tools Accessibility Guidelines
Check if it uses just the right amount of ARIA. For some people WAI-ARIA is the solution for all accessibility problems, adds functionality just by using it or see it as some form of miracle worker. Just add it to your web-app, and it will automagically make it more accessible. Alas, that could not be further from the truth. In reality, ARIA is a specification especially for assistive technology and in some regards, "a polyfill HTML". It helps developers to build or retrofit custom widgets in a way that screen-reader, for example, have the chance to understand them. First and foremost, WAI-ARIA is a contract with the user about adhering to certain usage patterns and to advertise that certain keyboard usage patterns are implemented. I think this general misunderstanding leads to findings like the analysis of the WebAim Million that uncovered that the more ARIA is used, the less accessible one website is. Or, as Bruce Lawson puts it: "...unless you really really know what you're doing, it's easy to make things worse with ARIA." So why the WebAim Million result is the way it is, is not hard to imagine, having this central misunderstanding in mind. Don't fall into this trap when building your web app!
Test your app with people with disabilities! Adhering to standards, being dogmatic and building things academically correct is just one part of the puzzle (alas, this aspect alone is often neglected). The other essential part is to talk with your users, test our assumptions and – ideally – ask people with disabilities in order to find out if your app (or any digital project in that regards) is really **built in an inclusive way.
If you want to use a web UI framework, check its accessibility. Sometimes is recreating everything from scratch is not the most economical option for your project and you reach out for established web UI frameworks like Foundation, Bootstrap, Material UI or Uikit. But bear in mind that it is important to have an idea of how accessible that UI framework actually is, and if it helps or hinders you when making your app more accessible. For help with that, research what's written about the accessibility of your chosen framework, or read articles like "The state of accessible web UI frameworks" from Derek Kay, who used a methodical approach in reviewing 20+ UI frameworks in regards to their accessibility features.
Keep updated regarding the Accessibility Object Model (AOM). The AOM will be an API to allow developers to modify and convey semantics to the accessibility tree, without having to rely on HTML (Reminder: the accessibility tree is a representation for the DOM tree for assistive technologies like screen readers or speech recognition software). To quote Hidde de Vries: "With direct access to accessibility info, we could set accessibility properties without markup, we could create accessibility trees for things that don’t exist in the DOM (like for contents of canvas elements), and testing accessibility may improve." Although both proposals and browser implementations of the Accessibility Object Model are still in "work in progress" state, it is very much worth following its development. To do that I would suggest following publications, tweets and talks from Leonie Watson (Blog, Twitter) and aforementioned Hidde (Blog, Twitter).
InFORM yourself about screen reader's form mode: The big screen readers for Windows operating system, namely NVDA and JAWS have special modes they switch into and offer interaction patterns that match that mode or circumstance. There is the browser mode, the so-called application mode, and something like the form mode. Since web apps predominantly consist of some kind of form input controls or collections of forms, it is well worth to look into the latter. Generally speaking screen reader users in form mode can only navigate to focusable element – and you have to keep this in mind, especially when dealing with input labels, descriptions, errors and their respective programmatic associations. My suggestion to dive into this topic: Accessibility Developer Guide's "Screen reader browse and focus modes".
If you learn about your framework by tutorials, be critical and don't just copy and paste. Many tutorial authors are not aware (or don't really care) about accessibility. This is very unfortunate, since video courses a great way of learning for many developers, and learning always starts with imitating and copying (the latter sometimes literally). What often also gets copied is the teacher's missing knowledge or disinterest in the topic of inclusive web developments. Fortunately, this appears to change (highlighting Wes Bos and Adam Wathan here), but it is still way too common. So if you are a beginner in web development (and you happen to read the whole way through this article, which is great in itself! 🎉), be on your guard.
That's it for my – I guess – last blog post of the year. Though I barely scratched the surface on each and every on this topics, I hope the list above gives you new ideas, keywords, or starting points for your learning. With this in mind: May 2020 be the year of improved accessibility on the web!