Accessibility testing

Is your team working with content, design or code? Embed accessibility testing into the workflow early to reduce long term technical debt.

Accessibility testing can range from quick checks to full auditing. The process may also be role-specific, focusing on content editors, designers, or developers.

Automated scanning

Automated tools detect less than half of accessibility issues on a page. Using these tools is best viewed as a helpful step in the testing process.

They can also generate false positives or raise warnings that need interpretation. Hence, they are insufficient for confirming accessibility.

Use both automated testing and manual testing to help uncover issues with design and content.

A range of testing tools are available, some of the tools available including browser extensions include:

• WAVE web accessibility evaluation tool
• axe DevTools
• IBM Equal Access Accessibility Checker
• ARC Toolkit
• HTML Codesniffer (bookmarklet)
• Sa11y the accessibility quality assurance assistant (bookmarklet)

Color Contrast Checkers

• Contrast Checker (WebAIM)
• Contrast Checker (Adobe)
• Link Contrast Checker (WebAIM)

Using Checklists

Checklists are also beneficial as part of the testing process, by translating WCAG criteria into an understandable language.

They may also be role-specific, focusing on editors, designers, or developers.

Although they are not a substitute for understanding WCAG guidelines, they are still invaluable. Use some of the following to help test for common accessibility problems:

• 18F Accessibility Guide - Checklist
• Easy Checks – A First Review of Web Accessibility (W3C)
• WCAG 2 Checklist (WebAIM)
• Checklist - The A11Y Project
• WCAG 2.1 Checklist with Filter and Links (Codepen)

Keyboard Only Testing

Many people cannot or do not use a mouse, and instead navigate with a keyboard. For the reason alone developers must ensure that all content on a page is operable with a keyboard.

Use the Tab key to check that all functionality receives visible focus and responds to common key presses (Enter and Space).

Default browser focus styling may be inadequate for some designs, or may be removed by CSS resets. Customs widgets may not be accessible by keyboard users without additional coding. Testing with a keyboard throughout development will identify these issues.