Three types of tests are always necessary for a complete testing of the accessibility of a website or even of individual web pages.
This approach is the only way to fully ensure that all aspects of accessibility have been considered and implemented correctly.
Basically, a distinction is made between three different types of tests. Automated tests provide an overview of errors or warnings relatively quickly. For example, if you need to test a website that consists of several hundred web pages, this volume can only be handled by way of automated testing. In addition, such tests can also be executed automatically during the build step and thus provide at least a basic assurance with regard to accessibility.
However, in addition to aspects that can be tested automatically, some tests cannot be automatic. For this reason, you cannot avoid manual tests (also called expert tests), in which accessibility experts check exactly these aspects. A classic example of a criterion that cannot be checked automatically is alternative texts for images: While automated tests can certainly help to check whether alternative texts exist at all (that is, whether the alt attribute has been used for <img> elements, for example), the meaningfulness and correctness of these alternative texts in relation to the image in question can only be verified by manual testing.
In addition to automated and manual tests (expert tests), full accessibility testing includes user testing, that is, by end users with disabilities. This kind of testing is the only way to find out whether a website is really accessible and understandable for the target group.
In this section, we’ll introduce you to a few tools to help you check various aspects of accessibility.
The developer tools of the various browsers enable you to read exactly the information from a web page that can also be read by screen readers and other assistive technologies. In this way, you can check whether this information is useful and, above all, meaningful.
In Chrome, first open Chrome DevTools via View > Developer > Developer Tools (on macOS) and then select the Elements tab, which opens the DOM tree for the web page.
Next to the DOM tree, you’ll see other tabs, as shown in this figure.
Select the Accessibility tab. Now, when you select an HTML element in the DOM tree, the area within the Accessibility Tree tab updates to show the hierarchical placement of that element the way assistive technologies “see” the element.
The same functionality is also provided by the developer tools in Microsoft Edge. To open these tools, select Developer Tools > Tools Developer > Development Tools... (on macOS) and then select the Elements tab. Then, the information is available via the Accessibility tab, as shown here.
Firefox also provides a similar functionality. To open the corresponding tools, select Tools > Web Developer > Accessibility, as shown in the next figure.
A special feature of Firefox’s accessibility tools, as shown in the next figure, is the simulation of the color vision deficiencies, protanopia (inability to see red color), deuteranopia (inability to see green color), tritanopia (inability to see blue color), and achromatopsia (inability to see colors in general). In addition, the web page can be simulated with reduced contrast.
Various tools are available for automated testing of websites and web pages with regard to their accessibility. In addition to the imergo® Web Compliance Suite, which is subject to a fee, other tools include WAVE, (the Web Accessibility Evaluation Tool) (https://wave.webaim.org/), which is available as a plugin for Chrome, as shown in the final figure; tota11y (https://khan.github.io/tota11y/); and Lighthouse (https://developers.google.com/web/tools/lighthouse).
Editor’s note: This post has been adapted from a section of the book Full Stack Web Development: The Comprehensive Guide by Philip Ackermann.