Accessibility has always had a tough time being a part of the definition of done in web development. With teams so heavily focused on getting their web content out the door at lightening pace, accessibility testing normally is done AFTER the content has been released to production.
Recently however, there has been a trend that has started to bring accessibility into the definition of done! That trend, is automated accessibility testing. These tools allow for development teams to see the accessibility of their content as they develop and it does not slow down their day to day agile process.
Teams are including automated testing as part of pipeline jobs using automated libraries like axe-core, using linters that include accessibility rules, or running an extension that tests the fully rendered content.
As great as this is, automation at best catches only the lower third of accessibility issues, opening the door for the content you create to still have major accessibility issues that are still not fixed. So what can we do to enhance our definition of done and catch more issues without slowing down the development process?
Introduce Keyboard Testing
Using a mouse is still the most common way teams test all actionable content. As simple as this sounds, testing your web content with keyboard is a large step to ensure your content is accessible for all.
In the world of JavaScript frameworks and the general lack of overall HTML knowledge, keyboard testing is essential for you and your team to ensure you can still use all actionable items on your site.
For example, let's looks a button that is created with <div> and ARIA.
<div role="button" tabindex="0" class="btn"
onClick="doSelect()">Select Item</div>
If you were to use a mouse and click it, you would see it activates and you can use it. That's it. Since there was no keyboard testing done, you would miss that it doesn't work with enter or space AND that there is no focus indicator on the button itself when its focus. Two MAJOR issues missed, but could easily be caught.
Another example would be a custom combobox or select dropdown.
<div role=”combobox” aria-label="Select a Dog"
aria-expanded="true" aria-owns="owned_listbox"> <input
type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="dog_list">
</div>
<ul role="listbox" id="dog_list">
<li role="option">German Sheperd</li>
<li role="option">Beagle</li>
<li role="option">Beagle</li>
</ul>
Although this may match the ARIA pattern perfectly, without keyboard testing I do not know if it works with arrow keys or that the trigger currently works with enter or space.
Benefits of Keyboard Testing
Keyboard testing includes many benefits such as:
- Catching missing focus indicators
- Ensuring your content works fully with enter or space
- Ensures custom combobox or select widgets work with arrow keys
- Helps build a foundation for manual testing
- Easy to learn, and apply agile environment
- Great transition into screen reader testing
How To Enforce It
The final thing with adding keyboard testing as part of your definition of done, is how to enforce your developers are doing it. Automated accessibility testing is easy to enforce. Developers have to show proof of an accessibility scan when making a pull request.
For manual testing such as keyboard there are a few ways in which you can check it has been completed.
- Your QA team can verify
- Code reviewers can also check it
- Write automated regression tests that check for enter and space
- Write automated regression scripts that check on focus there is an indicator
In Summary
Adding keyboard testing is a simple and effective way to go above and beyond the norm. Accessibility automation is a great fit for agile environments, but so is keyboard testing. By simply adding this to your day to day development you can catch so many more accessibility issues, ensure your content is usable with keyboard and no slow down your development process. A total win for everyone!
Top comments (0)