How to Write Accessibility Acceptance Criteria

Written by CJ | Sep 27, 2022

Accessibility acceptance criteria are a list of conditions that must be met in order for a feature to be considered accessible. They’re a helpful tool for development teams, as acceptance criteria can be much more specific than general technical guidelines such as the Web Content Accessibility Guidelines (WCAG).

When you create accessibility acceptance criteria at the first stages of development, you can make your team aware of the importance of inclusive design. You’re compelled to focus on users from the beginning — and that’s a great mindset for building better products.

Below, we’ll provide tips for writing accessibility acceptance criteria along with a few useful examples. For more guidance, send us a message to connect with a digital accessibility expert.

1. Accessibility acceptance criteria should identify risks and needs

Certain types of content may be more likely to introduce accessibility barriers. Your user experience (UX) team should complete a review of your specific product prior before you author your accessibility criteria, which should include documentation of the experiences of users.

Needless to say, your planning documentation must include the actual experiences of people who use screen readers and other assistive technology (AT). You may also create accessibility user personas at this stage, which are fictional representations of users with disabilities — but actual feedback from AT users is essential, and accessibility personas can’t replace those users’ experiences.

Identify specific components of your product that might introduce accessibility concerns. Examples include:

All user interface components
Media that relies on a certain type of perception (such as vision or hearing)
Components that rely on certain types of input (keyboard, mouse, or touch)
Content that uses color to convey information

Write out the potential risks for each component. For example, let’s say you’re adding a video player to a website. Risks might include:

If the video autoplays, people with mobility impairments might not be able to turn it off.
If the video player doesn’t support keyboard controls, screen reader users may not be able to pause playback.
If the video doesn’t contain accurate captions, people with hearing disabilities may not understand it.
If the video contains flashing content, it might trigger people with photosensitivity.

Your UX team can help to identify these risks, but every member of your team should stay involved. When your team understands how a barrier affects real-life users, they can create more effective solutions.

2. Describe the outcome, not the solution

Accessibility acceptance criteria should describe the ideal experience of the user. The criteria should not include a list of steps for addressing the barrier — even if the solution seems obvious.

For example, here’s a simple guideline for color contrast, taken from WCAG 2.1 Success Criterion 1.4.3: “The visual presentation of text and images of text has a contrast ratio of at least 4.5.1.”

That criterion describes the desired outcome (the text has a certain contrast ratio) without prescribing a certain combination of colors (“use black text on a white background.”)

Designers have room to interpret that guideline in order to make it fit with the product — and if designs change, they still have room to make adjustments.

3. When writing about accessibility, be specific

Accessibility acceptance criteria should be specific to the product or feature. Otherwise, you could simply refer designers and developers to existing frameworks like WCAG (and if you don’t have the resources to develop your own specific criteria, this might not be a bad idea).

Using the “Given, When, Then" approach can be helpful. For example, here’s a quick accessibility criterion for subheadings:

Given that I am on the webpage, when I read the subheadings:

The subheading identifies the content in the section
The subheading contains accurate semantic markup
The subheading has a contrast ratio of at least 4.5:1

Notice that these criteria do not explain how following the guideline affects users with disabilities. That’s the purpose of user scenarios — accessibility acceptance criteria need to be testable. If criteria discuss individual experiences (such as “Given that I am a Deaf user…”), they’re too situational to be tested.

4. Add new criteria and change your criteria frequently

Your criteria should change over time. Have a policy in place for identifying bugs, new technology requirements, and other issues that could necessitate additional criteria.

Referencing WCAG can help you update your organization’s accessibility acceptance criteria by following industry-wide best practices. While WCAG is a generic set of guidelines, it’s intended to apply to virtually all electronic content — when in doubt, start from WCAG, then tailor your criteria to make it more specific to your project.

5. Involve every member of your team, not just developers

Accessibility acceptance criteria help your team design better products. Well-written criteria can also help you adopt accessibility as an organizational value — but they’re not just for designers, developers, and other technical workers.

By communicating your accessibility strategy to your entire team, you can find more opportunities for improvement. A customer service representative may notice an issue with your feedback form that designers missed. A content writer might discover a bug with your site’s search feature.

When your organization is dedicated to inclusivity — and when they think about what accessibility means in specific scenarios — everyone benefits. For more guidance, download our free eBook, Developing the Accessibility Mindset.

View full post