Developing software is a precise process. Websites, mobile apps, you name it – you have to know the rules of the language, rules of the framework, all the minutiae. Naturally, when it comes to accessibility (a11y), engineers tend to apply what they already know – learn how to do it for your language, your framework, your app. "I don't know JavaScript accessibility. I only know HTML accessibility!"
However, a11y is much more effectively approached from a holistic standpoint. Go top-down: learn the concepts, learn the needs of people who rely on a11y practices. Then, no matter what language you're using, or what app you're building, you understand what needs to happen in order for your software to be accessible.
Compare learning a11y to learning auto mechanics. If you learn exactly what size socket wrench you need to do X specific job on a Honda Accord, you know exactly that: how to do that job on a Honda Accord. However, if you learn how combustion engines work in combination with electronics, you understand what needs to happen to accommodate a certain issue. Now you can fix a Jeep, a Ford, a Toyota or a Lamborghini. You know what causes the issue, and thus how to address it. Just as this imaginary mechanic is capable of much more than specifics, a developer versed in a11y as a whole will be able to address issues in any language or format.
For instance, one of the most common issues caused by JavaScript (JS) with regard to a11y is complications with navigation. A user might have trouble navigating by keyboard, for example, if focus and tab order are managed improperly (which can arise from many different sources). If a developer sought to learn JS a11y, they might learn how to properly manage focus in native JS. Now we know X code snippet that solves Y problem in Z context – a single point in a 3-dimensional matrix.
However, if that same developer sought to learn a11y holistically, they might start with the WCAG quickref (linked below). That way, they'd learn top-down all of the reasonable accommodations we can provide as developers. They'd learn needs and real-life applications - and save the code snippets for later. With that knowledge, we can provide a11y consideration in any language, any framework, for any platform with a quick visit to Stack Overflow. This gives a much wider and more complete understanding, instead of a cheat sheet with specific answers to specific questions.
So, save the specifics for later. Were you really going to check your notes next time you had to write that function, or were you just going to google it anyway? Learn a11y concepts, best practices, and needs. The specifics will follow.
Below are some links to get you started. World Wide Web Consortium has basically all the information you'll ever need for a11y; however, we've also provided links to guides from the perspectives of other established giants in the industry. Learn the concepts, and you won't have to alter your process to make your apps accessible – you'll be an accessible developer.
JS A11y Resources
- How to Meet WCAG (Quick Reference) – Web Accessibility Initiative customizable quick reference to WCAG 2 success criteria and techniques
- Accessible Messages with JS – This link is an example of WCAG's tutorials. W3C provides many other tutorials and guides in the Navigation panel on the linked page.
- Accessible JavaScript – WebAIM
- MDN JS A11y Guide – Mozilla