Twenty inclusive strategies for building web apps in 2020

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.

1. 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?
2. 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.
3. 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)
4. 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.
5. 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).
6. Be aware that WAI-ARIA Authoring Practices (AP) aren't gospel or standards. When you first stumble upon the authoring practices of W3C's Web Accessibility Initiative, and you care about the inclusive web, you possibly sigh in relief. "Finally", you may think, "a resource how to build accessible custom controls with modern JavaScript and ARIA." While this is true in part - the authoring practices show how ARIA should be used, have in mind that some AP are disputed: Because of the concepts, because of an accidental exclusion of other users, or because of inconsistencies in assistive technologies. As a general rule of thumb, look into the discussions in the Authoring Practices Github issues and see if there is a discussion around the practice you are aiming to implement.
7. Check your framework for accessibility documentation. Some of the major JavaScript frameworks helping you to build web applications have a whole section on inclusivity in their official documentation (React, for example). Study these resources thoroughly. There may be some gems hidden stating how you can implement accessible solutions in this particular framework with its feature and strengths. Also, if your favourite framework not yet has such a section in its official docs, but you are an accessibility specialist (or have some track record in another framework), think of contributing (and adapting) what you have learned so far. After all, it is open source.
8. 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.
9. Check clickable elements outside of forms – are they links or buttons? In modern JavaScript, it is so easy to make elements clickable (actually, it was easy in un-modern JavaScript before, cough onClick attribute, cough). But in accessibility terms, a (let's say) clickable does not make any sense and is actually harmful. There are many good articles out there explaining this over and over (like this article from Karl Groves), so I'm not trying to add another piece of content. Rather, I'd like to emphasize that is important to know when to use a link (generally speaking: for changes of location in your app) and when to use a button (generally speaking: to change the state of your app or to hide/show things). Marcy Sutton's talk "The Links vs. Buttons Showdown" is a great resource on this.
10. 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.

11. 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 app a standard for that: The Authoring Tools Accessibility Guidelines

12. 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!

13. 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.

14. 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.

15. 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).

16. Look into the advantages modern JavaScript frameworks can bring. It's not always black and white, especially when it comes to accessibility. Still, frameworks have a bad reputation in that regard. But it is much more exciting to think about how to use their undeniable powers – so to speak – for a good cause. In 2019, a whole bunch of people helped my to collect a list of ideas, resources, keywords and starting points answering the question: "In what ways could React, Vue, Angular and Co and their features actually facilitate inclusive designs?"

17. 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".

18. Check if the usage pattern of your custom components follow established patterns like modal or disclosure. In his book "Apps for All", Heydon Pickering writes: "Looking at JavaScript-driven web interfaces, by far the most common interaction style is based on showing stuff or hiding it or... oh, that’s pretty much it." I invite you to take such a deep look into your interfaces and code – does one control toggle the visibility of another? In this case, it's likely that you have built some form of "disclosure widget". Does another control trigger another containers visibility, and does the container try to render the rest of the interface inactive? Then this could be the "modal" concept. If patterns like these are present in your app, try to analyse the accessibility implications of both.

19. If your app is not fully client-side rendered, care about progressive enhancement. JavaScript is not always available. Its absence normally leads to single page applications not running at all, but not every web app is fully client rendered. Make sure that all of your content is perceivable and independent from processing through JavaScript. Andy bell uses the example of a disclosure widget to show how robust widgets can be built: https://hankchizljaw.com/wrote/a-progressive-disclosure-component/.

20. 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!