An Introduction to Web Accessibility Part 3: Accessibility Testing

In the final part of this series, I’ll introduce practical ways you can test your websites for accessibility.

Previous articles in this series: part 1, part 2.

The Medium platform does not fully support headings, a hyperlinked table of contents or clickable footnotes. For a better reading experience, read the full article series on one page here.

Test With a Keyboard

Test your website with a keyboard.

Keyboard accessibility is one of the most important aspects of web accessibility because many users rely on a keyboard. Filling out forms is often faster with a keyboard. Screen reader users typically interact with websites using the keyboard alone. Users who find it difficult to perform fine motor movements use the keyboard. Some users use voice input software or hardware like an assistive switch which mimics the functionality of a keyboard.

Use the tab and shift+tab keys to move between elements on the page, enter to activate controls and the arrow keys to move focus between elements in a composite widget like the nodes in a tree view¹. Watch out for the following:

• Is there always a focus outline that visually shows which element is currently receiving keyboard focus?
• Does the order which elements get focus or focus order make sense? By default, focus order is the order which elements appear in the DOM.
• When focus lands on an element or a widget, can it be fully interacted with via a keyboard? For example, buttons should be activated when pressing either space or enter. Using native HTML provides this functionality for free. For custom widgets, consult the Aria 1.1 Practices Guide for implementation guidance and expected keyboard behaviour.
• Are there interactive elements that can’t be reached via a keyboard?
• If there are controls or information that are revealed on mouse hover, is there equivalent behaviour when the triggering element receives keyboard focus? Can newly revealed controls be tabbed to and activated?
• When activating an element via the keyboard would cause it to be removed or moved to a different part of the DOM, does focus get moved to a logical location? For example, does activating the close button of a modal dialog restore focus to where it was before the modal was opened?
• Are there keyboard equivalents for drag and drop operations?

Use Automated Testing To Catch Common Issues

Automated accessibility testing can highlight certain types of issues such as missing alt text in images, insufficient colour contrast, unlabelled form fields or incorrect heading structure. It is scalable, quick to run and can draw attention to problematic parts of a site.

However, automated testing can only discover up to 40% of accessibility issues². It is possible for a site to perfectly pass automated tests while actually being completely unuseable. Automated testing also cannot assess the appropriateness of the alt text set on an image, find controls that only appear on mouse hover, flag a pseudo table built via divs that should be replaced with an actual<table> element or determine if a custom widget is actually easy to use in practice. Hence, it should be used together with actual manual tests.

There are many automated testing tools available. I recommend starting with the Axe extension or Lighthouse’s accessibility audits. Lighthouse uses the Axe engine for accessibility auditing and is built into Chrome’s dev tools.

Test With Actual Software And Users

To ensure your websites work well, test on various browsers, devices and assistive technologies. This will expose many problems that won’t show up in automated tests.

Start first by testing with a keyboard, followed by a screen reader. Screen reader testing allows you to evaluate your websites from an entirely different perspective. Because of their use of semantic markup, testing with screen readers catches problems that would have been hard to spot visually. For instance, checking if reading order makes sense, labels on form elements, heading structure, table markup and assessing the accuracy of alt text in images.

If you’ve never used a screen reader before, it will be frustrating at first, and you may even mistakenly think your site is inaccessible because you aren’t using it correctly. Here are some guides to using the NVDA screen reader on Windows, VoiceOver built into the Mac and screen readers built into iOS and Android devices. Note that with the exception of NVDA, the other screen readers are built in and don’t need to be installed.

Include users of various types of software and hardware in usability testing. For example, users of screen readers, magnification software, voice input or a switch. This provide valuable feedback about how people actually use your site, and ensures it is not just accessible but easy to use for everyone.

Evaluate Accessibility of Third-Party Dependencies Before Use

When deciding whether to use a third-party dependency for a UI component, ensure that it is already accessible. This is critical because it is much harder to replace a dependency or try to fix it later, especially if it is a complex widget or is used for core functionality on your site.

Even if it claims to be accessible, actually do some testing yourself first to verify its accessibility. Consult the Aria 1.1 Practices Guide for expected behaviour. Ensure that they also meet this checklist of basic custom control requirements. Also apply this process on existing or new reuseable components in your application, since accessible components make it easier to build accessible applications.

Look through issues that other users of the library have reported. If reported accessibility issues are not addressed in a timely fashion, use a different one instead³.

Conclusion

Developing content that is universal to all users allows for more access, more exposure, and more dialogue. We should empathize with everyone who uses the internet, and we should design our web content to optimize for as much access as possible. The guidelines and examples above are just the first steps towards making this a reality.

Using semantic HTML is both an accessibility and software engineering best practice. It enriches web content with meaning, enabling the presentation of information in alternate formats to suit users, automated search engine crawlers and other programs. Using semantic HTML also avoids reimplementing built-in elements, an instance of code reuse and the “Don’t repeat yourself” software engineering principle.

This 3 part article series is just the beginning! In the future, I will be writing in greater detail to explore topics such as applying these principles in the context of React applications, understanding the accessibility tree and building accessible custom widgets. Thank you for reading!

Feedback

I’d love to hear from you. Please see this page for ways to reach me.

Acknowledgements

I’m very grateful to Joseph Goh, Ziwei Ang and my colleagues on the MyCareersFuture team at GovTech for the incredible support and insightful suggestions. I’d also like to thank Jordan Lee for his expert editorial support and writing advice.

Footnotes

1. When testing websites using a keyboard with Safari on the Mac, you must first enable the following setting: System Preferences > Keyboard > Shortcuts > Full Keyboard Access : All controls. I’m not sure why Apple disables this by default.
2. Granted, this is an extreme example, but the point stands.
3. This applies to all types of issues, not just accessibility related ones. If there are many open issues, then check that the library is at least updated regularly to fix the most important problems.