Accessibility in JavaScript Applications
I recently watched an excellent lecture by Marcy Sutton on accessibility in JavaScript applications on Frontend Masters.
Marcy Sutton is currently the Lead Software Developer at Gatsby (one of my favorite tools for building fast modern web apps) and she has been a professional in accessibility for quite some time. She was a Developer Advocate on the axe-core team and she was an Accessibility Engineer at Adobe.
Her lecture takes you through the many different ways that accessibility affects the work we do as JavaScript developers, such as the importance of testing and how to build accessible components. In this talk, Marcy provides a number of resources and tools that developers need to create modern accessible solutions.
In fact, Marcy’s lecture covers so many topics that it would be a disservice to her for me to try and go over all of them in this article. Instead, I will go over five of the biggest takeaways that I received from this lecture, and how each of them can help designers and developers create more accessible products.
Accessibility Debugging
The first topic I’m going to go over is debugging accessibility in our applications. As web developers, it is our responsibility to make sure that the code we’re shipping is accessible to all of its users, and as part of that responsibility we should be taking the time to debug and audit the products we build. There are several web extensions that can do much of this auditing for us automatically, such as axe. But automated tools like this can only do so much.
To truly test the accessibility of your website, you need to test your application by hand. Render your application in a browser and try to navigate your site using only a keyboard. Make sure that you’re able to perform the same necessary actions that your users would. If you find yourself unable to access a portion of your site, or if your focus becomes trapped in a section of the page that you can’t navigate away from, that can be a significant issue for many of your users. A large number of your users will be accessing your site the same way, so it is imperative that they can perform all of the same actions that a user with a mouse could.
The same goes for your blind and low-vision users. Low-vision users face a number of accessibility issues on the web. To ensure that your site is accessible to these users, try magnifying your browser window to at least 200% and see if your site is still usable. Do you have to scroll horizontally to navigate through the entire page? That can be less that ideal for many low-vision users, making a what can be a simple task significantly more difficult. For blind users, it is important that you test your site with a screen reader, and make sure all of the content on your site is perceivable through it.
Screen readers can have a definite learning curve, so it helps to have some screen reader command cheat sheets handy, which Marcy also provides in her course along with a large number of other accessibility resources: https://dequeuniversity.com/screenreaders/
Using Proper Semantic Elements
The proper use of semantic HTML elements is something that Marcy stresses repeatedly throughout her course, and for good reason. In her course Marcy demonstrates that it takes several lines of code to achieve what could be done by using a simple <button /> tag. It becomes much easier to forget to include the basic accessibility features these HTML tags provide when trying to create your own custom versions of them. You don’t want your applications to be “div soup” as Marcy puts it.
Another one of the baked in benefits of some semantic HTML elements is that they already have ARIA landmark roles defined in them by default. ARIA landmarks provide roles to certain sections of your code like banner, main, navigation, form, etc. and screen readers are able to navigate pages by these landmarks and bring up lists of each landmark. Having these landmarks on a page provides a huge benefit to your screen reader users.
To get a detailed description on what elements have ARIA landmark roles and which ones they have, check out this page on the W3C website: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html
Focus Management
Part of Marcy’s course covers focus management, and how to send focus to different parts of your app when the user needs to be alerted to new content. This topic is of utmost importance to keyboard only users and screen reader users. The way that these users interact with the web is entirely from the keyboard, so if there’s something wrong with the focus management, then it significantly detracts from their experience on your site.
Another aspect of focus management is making sure that there is a visible focus indication on each of your focusable elements in your site. This is extremely important for sighted keyboard users because the visible focus indication is their only way of telling where they are on a page. Without a visible focus indicator, the site they’re using might as well be useless.
Utilizing focus management can also allow you to greatly enhance the user experience of your app. It allows you to build skip links that enable keyboard users to skip the navigation options and move the focus directly to the main content. You can create interactions that allow you to move focus directly to new content when the user triggers them, such as automatically sending the focus to the first list element in a dropdown when you open it.
These are both things that Marcy shows you how to build in detail using React, so definitely check it out if you have the chance. If we all develop with accessibility and focus management in mind, we can all build much more accessible and usable components.
Automated Testing
One of the biggest takeaways I got out of this course was the importance of automated testing. Testing can add a huge level of confidence to your code, and prevent you breaking aspects of your app that you would have otherwise missed. There are different kinds of automated testing:
Unit Testing
Unit testing allows you to test the functionality of your components on their own. This is for when you want to test how a component works in isolation, without any calls to an API or rendering the whole app. Jest is a fantastic tool for writing tests in JavaScript, and along with the all of the helpful utilities provided by Testing Libraries, they make it a breeze to query the DOM and make assertions for your components’ tests.
Integration and End to End Testing
There’s a lot of debate around what the actual difference between them are, but Kent C Dodd’s describe’s end to end tests as “a helper robot that behaves like a user to click around the app and verify that it functions correctly” while integration tests “verify that several units work together in harmony”. Check out his article, Static vs Unit vs Integration vs E2E Testing for Frontend Apps, if you want to learn more. These tests can be written in Cypress, which has quickly become the favorite tool of integration testers since it arrival in the JavaScript testing scene.
The Takeaway
However, the biggest takeaway from automated testing is not how to write them — it’s the why. The biggest reason why you should be writing tests is the confidence that it gives you. And once you start testing with your accessibility patterns in mind, it opens up a huge number of possibilities that allow you to ensure the accessibility of your application, and increase your confidence in your product even further.
Manual Testing
User testing is the most valuable way to get data on the usability of your app, especially when accessibility is concerned.
Marcy makes a point in her course at the end of the testing section, that despite all of the great things automated testing can do for us, it can’t do everything. We still need to do more to make sure that our sites are fully accessible and usable.
Manual testing includes some of the accessibility debugging steps that I mentioned earlier in the article, such as keyboard testing, screen reader testing, and magnification testing. But what I believe is far and away the most useful form of manual testing, is user testing.
User testing is the most valuable way to get data on the usability of your app, especially when accessibility is concerned. We as developers can fiddle around on screen readers with our eyes closed all day long, but none of it will give us as much useful information as an actual user who is blind, testing your app. Many people who are blind use screen readers as a part of their everyday life, so they are much better at using them to navigate our applications than we are. Not only that, but we can only do so much to try to understand the pain points that they experience in applications. And this of course does not only applies to our blind users, but to all of our users. The best way we can truly understand is by allowing our users to tell us themselves during user testing.
Fable is a great example of a company who provides this kind of accessible user testing as a service, be sure to check them out if you are interested in doing some user testing.
Conclusion
Accessibility has been changing the way that we design and develop for the web, and I think that change is good. It is important that we keep up with the accessibility trends and make sure that we’re doing everything we can to make our products as accessible for our users as possible. The world has been changing to be more inclusive to people with disabilities, and it is a welcome one. Making the things we create on the web more inclusive to all users can greatly improve the quality of life for everybody that uses the web.
At the beginning of her course, Marcy describes accessibility as something she can’t turn off in her brain and that she hopes her course flips that switch for her viewers as well. My hope is that each of the takeaways in this article helped you begin to flip that switch in your brain as well, and that you’ll begin to design and develop with accessibility in mind.
