Accessibility testing (a11y) is an important part of testing any application. In my experience, it's not done often enough, although more and more companies are getting involved here given legal issues that have cropped up in the last couple of years.
Like anything else that is designed by UX or developed by Developers, a11y needs to be tested.
If you are going from zero a11y to some a11y, then lots of testing needs to occur and lots of bugs can be found. The types of testing that's typical here is functional testing, regression testing. Because code is modified to assist in a11y, you still need to ensure the application is functional and doesn't cause any regressions. a11y is really about adding more testing to your process. This can be a large effort in getting started.
Accessibility is a standard protocol by the W3C listed under WCAG guidelines and a lot of people focus on AA level (there are 3 levels: A, AA, AAA).
There are lots of things to consider when a11y testing, including (non-exhaustive list):
- Visual acuity (blind, colorblind, restrictive vision)
- Physical dexterity (ex: keyboard-only navigation, not everyone can use a mouse)
- Hearing (ex: do videos/audio contain captions, subtitles)
- Screen sizes (is your app mobile responsive?)
- Language (localization, internationalization can be considered an accessibility concern)
How do you test a11y?
You can manually test a lot of this using tools:
- Use screen readers. There is paid software for this at the OS level or ChromeVox as a Chrome extension. Phones also have built-in a11y controls.
- Change color contrast on your device. This tests for different colorblindness.
- Zoom in/out on your app
- Google Lighthouse in Chrome DevTools can test for some accessibility, but not all.
- Chrome DevTools Elements tab also shows some ally interpretation when you use the select tool to select any element on the page.
- Keyboard only navigation. Turn your mouse off. The biggest bugs here are "keyboard traps".
- Use aXe. This is considered a de facto, best of breed tool for a11y automation. It also can be used with Selenium WebDriver.
I caution you to not let yourself get caught up by "automate everything" approach. Not everything can or should be automated and there are lots in a11y that can't be. Use automation and other tools where feasible.
What do you test for a11y?
- All software, including desktop apps, web apps, mobile apps.
Who performs a11y testing?
- Testers can perform a11y testing
- Can outsource to 3rd party companies that specialize in a11y testing
Do you postpone testing if there are a11y bugs?
- This depends. I'd lean towards no, but depends on the bug. If there are bugs that need to be addressed, you can fix them in your SDLC/Agile process for the next release (fast follow up).