Web Accessibility Cookbook

Chapter 13. Debugging Barriers

Understanding what makes an accessible website and knowing what to look for when implementing it is essential, but it doesn’t protect you from making mistakes anyway.

Furthermore, you often work with others on a website. The more people are involved, the easier it is to introduce bugs. More people from different disciplines means more potential sources of error.

Automated testing software doesn’t replace manual testing, but it can help catch low-hanging fruits and find sloppy mistakes. Paired with debugging tools, they allow you to prepare your websites for manual testing using keyboards, screen readers, and other assistive technology.

13.1 Find Accessibility Issues Automatically

Problem

Looking for accessibility issues by scanning the code manually is time-consuming, challenging, and error-prone.

Solution

Use automated testing tools to find easily detectable accessibility issues before you proceed to manual testing. The code in Example 13-1 includes several accessibility issues for the purpose of testing.

Example 13-1. Testing demo: Inaccessible sample code in HTML

<h2 aria-label="Registration">Sign Up</h2>

<form aria-labelledby="h2">
  <input type="text" name="username">

  <button>
    <img src="send.jpg">
  </button>

  <p>
    <a href="#" aria-hidden="true">Disclaimer</a>
  </p>
</form>

You can test the code in Example 13-1 using different browser extensions. Five popular testing tools are axe DevTools (see Figure 13-1), Google Lighthouse (see Figure 13-2 ...