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.
Related: Tips for Creating Accessibility Personas
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.
Related: How Accessibility in the Web Development Process Saves Time
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.
Related: Universal Design: An Introduction for Digital Content Creators
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.
