Testing is an important practice that helps product teams catch defects early on, before they make their way into a production environment.
Automated tests can run against every pull request or on intervals. Including them inside a continuous integration and continuous deployment (CI/CD) pipeline is a software development best practice. In order for these tests to be effective, they must also cover the needs of people who use assistive technologies.
Automated testing only captures around 30% of accessibility defects. Most accessibility defects originate from human decisions, not bugs in code. So manual testing must also be conducted with assistive technologies such as keyboard-only navigation, screen readers, and voice input.
Here are a few ways to bake accessibility into testing a testing strategy:
Design Plugins
Designers can use these Figma plugins to ensure the accessibility of their work:
- Able: Run Able, then select two layers. The Able panel will show you the contrast ratio between the fill color of each layer, tell you if it passes WCAG AA and/or AAA, and give you examples of what different text sizes and boldness look like. Use the dropdown to view how those colors look to people with different types of colorblindness.
- Contrast: Another color contrast checker. Select a layer, and Contrast will compare the fill color to the color directly behind it.
- Color Blind: Simulate different types of colorblindness across any single layer, group, or frame. If desired, Color Blind will generate a screenshot of the simulated view that you can add to your file.
- Text Resizer: Use this plugin to quickly change your base font size. This will help you test what your screens look like for users who resize text.
- Axe for Designers: Use this plugin to check for missing headings, readability issues, touch target sizes, and more. You can use it to add accessibility annotations, too!
Linting
Linters will analyze code quality and serve as the first line of defense against defects. Linters are often used to enforce stylistic formatting rules and suggest better solutions. They can either highlight issues in code or reformat code to adhere to a rule when the developer saves their work. Linters are often extensible, using plugins to provide additional functionality. That additional functionality includes flagging accessibility issues such as missing alternative text on images, omitting the lang attribute from <html>, and many more.
Unit and End-to-End Testing
Another way to buttress an application’s accessibility support is to factor accessibility into your unit and integration tests. React Testing Library includes robust support for accessibility. Instead of using getByTestId, use the semantic HTML queries to guarantee that the application works with browser accessibility APIs. Unit tests should also cover a component’s accessibility features, such as internal focus management.
For end-to-end testing suites, many of them have Axe Core plugins that can assert an entire page’s accessibility. Additionally, they can check a page’s accessibility at different viewport sizes. Another way to use end-to-end testing to maintain accessibility is to write keyboard-only tests to ensure that interactive elements are tabbable and focusable, and that focus is properly managed. These tests ensure that it is possible to use the application without just a mouse cursor. Here are some accessibility plugins for end-to-end testing:
- Cypress-axe for Cypress
- Axe-playwright for Playwright
Use the CI/CD Pipeline
Integrate all testing and linting into the application’s CI/CD pipeline so that accessibility checks are running regularly and automatically. If any of these checks fail, the work should be blocked from merging until the issues are resolved and the checks are passing. Doing this helps prevent many accessibility defects from getting merged into the code where they can become larger and much more expensive to fix.
Brower Extensions
Browser extensions are invaluable tools for designers and developers looking to identify and resolve accessibility issues within their websites or applications as they appear to users. These extensions analyze web pages, highlighting potential accessibility barriers such as missing alternative text for images, insufficient color contrast, improper heading structures, or missing ARIA labels. By providing instant feedback and visual indicators, these extensions allow teams to quickly detect and address accessibility defects during the development process. Some extensions even simulate different user scenarios, such as keyboard-only navigation or screen reader use.
Here are some useful browser extensions:
- Axe DevTools for general accessibility issues
- HeadingsMap for displaying all page headings to show document structure
- Accessibility Insights for guided accessibility checks, particularly useful for teams new to accessibility testing
- The web browser’s accessibility tree, which can be found in developer tools
ANDI is a javascript bookmarklet for use on computers that prevent access to developer tools
Don’t Rely on Automated Testing Alone
Integrating accessibility into automated testing is a great technique to prevent inaccessible code from getting into a codebase, but it is not a guarantee that the app will be accessible and usable. In fact, most accessibility issues cannot be detected by automated tools, which is why it is very important to conduct manual testing, as well.
To be as efficient as possible, teams should combine automated and manual testing.
Developers should test their work not only with a cursor, but also with assistive technologies. Pull requests templates should include checklists for the developer to confirm that they have tested their work on assistive technologies and that their work is usable without any additional burden. To avoid this process from becoming a bottleneck, use a “user-facing” label for any user-facing work so that it can be manually reviewed at a later time.
How We Know We’re Doing This
- Our units tests query for semantic HTML, keyboard focus, and any other functionality that might impact users with disabilities
- Our CI/CD pipeline is blocking any accessibility issues from getting merged into the codebase
- Our end-to-end testing covers keyboard navigation, focus management, and full page accessibility
- Our accessibility linting is integrated into the application
- We are using browser extensions, and still conducting manual testing after these tools show zero accessibility issues
- Our manual testing work is done regularly
How We Know We’re Coming up Short
- Our unit tests are written, but only account for click actions
- Our pull request templates might have a single checkbox that accessibility has been validated, even though there are no accessibility specialists on the team
- Our accessibility linting is configured locally on a developer’s machine, if they choose to use it
- Our manual testing with assistive technology is conducted only before a major release
- We are using browser extensions, but not conducting manual testing after they show that no accessibility defects remain