Accessibility checklist

What we can see, hear, say, and touch affects how we interact with technology. And these abilities are not static; they can be impaired situationally, temporarily, or permanently. This diversity means there isn't a "normal" experience or user, and that technology needs to be accessible to people with varying levels of ability.

Everyone who works on government websites, including researchers, visual designers, content strategists, developers and project managers, has a hand in making public resources more accessible to the public. By law federal websites need to be Section 508 compliant, which follows the W3C Web Content Accessibility Guidelines (WCAG) 2.0 Level AA).

What to check for

Critical

Failing one of these checks will cause serious problems and/or stop most users of assistive technology from using the site.

• Site is keyboard accessible. All interactions should be accessed with a keyboard
• Site is free of keyboard traps. The keyboard focus is never trapped in a loop
• All form inputs have explicit labels.
• All relevant images use an img tag.
• All images have alt attributes.
• Multimedia is tagged. All multimedia has appropriate captioning and audio description
• Text has sufficient color contrast. All text has a contrast ratio of 4.5:1 with the background

Less critical

Failing one of these checks will cause problems or increased frustration for certain users.

• Site never loses focus. Focus is always visible when moving through the page with the keyboard
• Tab order is logical.
• Form instructions are associated with inputs.
• Site doesn’t timeout unexpectedly. Identify elements that may “timeout” and verify that the user can request more time
• Tables are coded properly. Tables have proper headers and column attributes.
• Headings are nested properly. Heading elements are nested in a logical way

Minor

Failing one of these checks will cause problems or frustration for a small number of users.

• Frames are named. All frames have a name element.
• Flashing elements are compliant. Elements that flash on screen do so at a rate of less than 3 Hz
• Language is set. The language for the page is set, and the language for sections on the page that differ from the site language are set.
• CSS is not required to use the page. The page makes sense with or without CSS.
• Links are unique and contextual. All links can be understood taken alone, i.e ‘Read more - about 508’
• Page titles are descriptive.
• Required plugins are linked on the page.

Also consider

• Are you testing regularly with a diverse set of users?
• Can you quickly understand the main points of the content?
• Can you quickly understand the meaning of the page and complete your task?
• Can you easily read and comprehend textual information on the page?
• Are your touch targets large enough and easy to reach?
• Can you understand key information and perform critical tasks on a mobile device?

Automated testing

There are many tools that can be automated in your Continuous Integration setup to help test for accessibility. https://accessibility.18f.gov/tools/ is a good place to start learning about these tools. Pa11y and Lighthouse are two common and useful tools.

Evaluating and measuring accessibility can be difficult. Automated tools like Lighthouse and Pa11y can help, but they cannot replace talking to and working with people who experience disability. This, too, can be difficult – especially in government – where there are legal statutes that both require accessibility and place heavy restrictions on how agencies can recruit participants for usability testing of any kind, including testing for accessibility.

Resources

• 18F Accessibility Guide
• Accessibility for Teams
• Microsoft Inclusive Design, particularly the Inclusive Design Toolkit
• WebAIM color contrast checker