Web accessibility is an increasingly important component of web development. In the third part of this series, we talk about screen readers and best practices for making your websites accessible on them.
In the process of implementing accessibility compliance (Section 508, WCAG 2.0 and WAI-ARIA) for KendoReact, our suite of native UI components for React, we learned a lot on the topic. With this blog series, our goal is to introduce fellow engineers to web accessibility and share our practical knowledge and best practices.
This blog, part III of a series on accessibility, focuses on the technology that helps us improve the accessibility of our websites, specifically how to work with and optimize our content for screen readers. We decided to dedicate a whole article on this topic, because screen readers are the primary tech that makes the web accessible to blind people. In addition, working with screen readers isn’t straightforward and presents a lot of technical challenges.
Assistive Technology
Assistive technology is the industry term that includes all software and hardware designed to help people with disabilities. Input devices include mouth sticks, head wands, big trackballs, specialized keyboards, voice recognition software. Output devices include screen magnifiers, screen readers, braille displays, hearing aids, software with natural language interfaces and more. Some of these enhance an existing technology, others provide an alternative way to interact with a computer.
Screen Readers
Most assistive technologies work on the level of the operating system and web developers do not need to do anything additional to enable them to function properly. However, with screen readers things tend to be a little more complicated. What screen readers do, in essence, is parse the HTML, then describe and explain it using natural language. The quality of that voice description depends directly on the quality of the code. So, naturally, screen readers are a primary concern for web developers working on making their websites more accessible. In the following paragraphs we will look at some of the best practices when optimizing our web assets for screen readers.
Write Semantic HTML
The best practice to help screen readers do their job properly is to write semantic HTML – that is, to write valid HTML, follow best practices and use elements according to their intended purpose. For example, if something looks and behaves like a button, make it a button, not a <div>. If it is a heading, use the <h> tags and not some inline CSS.
The formal definition of the semantics of HTML elements can be found in the living standard of HTML
In real life this is not so simple, of course. This brings us to the next sections.
Follow the Spec
As with any fundamental technology, the Internet has multiple standardizing bodies. The World Wide Web Consortium (W3C) is one of them and the Web Accessibility Initiative (WAI) is part of it. We as developers need to follow the Web Content Accessibility Guidelines (WCAG), developed by WAI, which is the general standard for web accessibility.
The design practices I went over in Part II when discussing the different types of disabilities are described in greater detail in WCAG. It’s important to note that WCAG is a living standard that is actively being improved. The most recent version as of the time of writing is 2.1.
WAI developed Web Accessibility Initiative - Accessible Rich Internet Applications Suite (WAI-ARIA) - the technical standard for how to write our code. We as developers need to follow this spec for screen readers to work properly.
For brevity, in the next paragraphs I will refer to WCAG and WAI-ARIA as “the spec.”
Automated Testing
There are a variety of scanners that can automatically do checks covering many of the compliance rules that we are required to follow. For example, most automation software can easily scan for missing attributes and elements, check color contrasts or validate the HTML. A good practice is to do at least a quarterly scan of your site. And if you are really dedicated, you can include this step in your CI and CD process. Here is a list of good-quality scanners in no particular order:
- Google Lighthouse - https://developers.google.com/web/tools/lighthouse/
- Axe - https://www.deque.com/axe/
- Wave - https://wave.webaim.org/
- Powermapper - https://www.powermapper.com/
- Dynomapper - https://dynomapper.com/
- Monsido - https://monsido.com/features/web-accessibility
- Various other tools - https://www.w3.org/WAI/ER/tools/
Manual Testing
Unfortunately, automation can take just a small part of the big picture. If you want to achieve meaningful results, you have to manually test your site. The most practical way to perform such a test is to close your eyes and use only a keyboard and a screen reader to perform a variety of tasks on the website you’re reviewing.
This is the point when I discovered how difficult accessibility testing really is.
Navigation
With your eyes closed, you cannot use a mouse. Keyboard navigation in the dark is much harder than with visual input. A lot of your solutions may not work as well as you had hoped once you stop seeing the screen. You will probably discover scenarios that you’ve failed to take into account. In short, offering good, working keyboard navigation is very hard.
Auditory Complexity
The market provides multiple screen readers and they are usually very hard to understand. You may struggle to make sense of what you hear. The reason is that screen readers do not just read the screen using text-to-speech. Their task is harder: they need to describe the UI in enough detail so you understand its structure. Screen readers can be understood well only when you provide them with simple constructs in simple scenarios. So you need to work very hard to simplify the information architecture of your site.
Inconsistencies
Each screen reader has its own subtle interpretation of the spec and behaves slightly differently on each browser. You will encounter a lot of grey areas where following the spec is just not enough to make all screen readers provide meaningful output. In those cases, your implementation needs to make a compromise that works ok in most combinations of readers and browsers.
In our practice we’ve discovered a few combinations that work well for testing purposes:
Jaws
Jaws is one of the oldest screen readers on the market. This means that it is one of the most popular ones. It has numerous users, so you need to support it. But its age also means that Jaws needs to support a lot of legacy use cases. As a result, it is often not very compliant with the spec and difficult to work with. In our practice, we found that Jaws works best with IE.
ChromeVox
ChromeVox is the newest reader (as of the time of writing this article) and, consequently, most compliant with the spec. Its young age means it is still not very popular. It works best on Chrome.
NVDA
NVDA is another new reader with good compliance with the spec. It is very popular and works best on Firefox.
Conclusion on Manual Testing
When a reader works well on a particular browser, this gives you some confidence that its users will use it primarily on that browser, though there are no rules and the possible scenarios are many. However, given that we usually work with limited resources a good practice is to focus only on the popular combinations above and test often, instead of covering all possible combinations of readers and browsers, but doing it less often.
To back up our statements with data, here is a link to a reputable screen reader user survey that sheds light on user adoption of screen readers.
Third Party Testing is Last
It is advisable that you test with people with disabilities or get accessibility feedback from clients. The best practice is to do this only after you have done your homework with in-house manual and automated testing. It is our responsibility to first make sure their user experience is not completely broken. Only then will you be able to get meaningful feedback from your users.
Conclusion
Developing for accessibility is hard. Often it may feel like trial and error, with no clear, universally accepted solution. We in the KendoReact team understand the complexity of the situation, which is why we did this blog series. In a way, we are limited by the available technology – though as engineers we have always worked with limitations. Software has never been and will never be perfect. But making the most with the resources you have available is the mark of a master craftsman.
The Whole Series
- Part 1: Introduction - An introductory article on web accessibility that attempts to answer what accessibility is and why it matters.
- Part 2: Types of Disabilities and Best Practices to Accommodate for Them. Here we further define the problem, break it down into sections on different disability types, suggesting individual solutions.
- Part 4: More Best Practices and Resources. Here we go over more practices about organizing our workflow and further explore how to make this daunting task manageable. (coming up)