Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Improving accessibility with accessibility acceptance criteria

A GOV.UK blog post from 2018, describing GDS’s use of ‘acceptance criteria’ for accessibility testing.

These criteria are more specific than general WCAG guidance, and concentrate on specific checks to make at the component level for specific components. For example, GDS’ accessible autocomplete component must:

• be focusable with a keyboard
• enable the user to navigate the available matches using touch or keyboard
• inform the user when a match is selected
• inform the user which number the currently selected match is – for example, 1 of 3 (optional)
• inform the user if a match is pre-selected
• …and so on

These criteria are a way of recording decisions made early on in development, and provide a sense check against making breaking changes when iterating the component in future. They also serve to raise awareness of accessibility issues from the start.

To write criteria such as these, start with accessibility needs by identifying where there is a high risk of introducing an accessibility barrier, and documenting how to prevent it. The hard work has often already been done in the WCAG guidelines, so extract rules pertaining to what you’re building, and link back to the guidelines for context.

Criteria are most useful when they’re specific and testable. Don’t be too generic. Also avoid defining the solution; describe an outcome instead.

Continue to refine your criteria over time, e.g. when encountering bugs, add further criteria and treat them like a failing unit test.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.