A well-written DoD can serve as a checklist for the team, provides a shared understanding on the quality of the work, and helps the product owner in the acceptance process.
When you include accessibility in the DoD, you make it an important quality of your product. Each backlog item should comply with the Definition of Done, it helps you spot and tackle accessibility issues before they’re deployed to production.
An effective DoD for accessibility
You already have general checks in your DoD, checks like:
- Documentation is updated
- Unit tests were written and pass
- Meets acceptance criteria described for the user story
These checks help the team and the PO have a common understanding of “Done”. When you want to add accessibility to this list, we need to be specific about what accessibility means.
Accessibility means that products work for people, so to be truly accessible, you need to test your product with real people (including disabled people). This doesn’t mean that you have to include usability testing in the DoD. In reality it’s not always possible to do usability testing for every new feature. When you do usability at the end of each sprint and it’ part of your process , you might still include it in the Definition of Done for the sprint. Probably not on your checklist for backlog items though.
There are things that we can reasonably check for each feature. We can run automated tests, manually test against the accessibility guidelines, or check that the content style guide was followed. These checks help you keep your products accessible.
For a DoD to be effective, each requirement on the list should be checked off for a feature to be marked as Done. If you don’t plan on doing that, then there is no reason to include a check.
Examples
These are some examples of items to include in the Definition of Done.
- Passes automated accessibility tests
This is the minimum you can (and should) do. There are plenty of tools available to test against the accessibility guidelines. Some common ones are Wave, aXe, Lighthouse, and Tenon. They all test differently, so it’s best to use a combination of tools. Here’s how different accessibility testing tools compare.
- Meets WCAG 2.1 requirements
The best way to ensure WCAG 2.1 conformance, is having each feature reviewed by an accessibility expert. This expert can be internal or external, as long as they are knowledgeable and experienced.
- Accessibility statement is updated
If you have an accessibility statement on your website, it should help disabled people understand whether your products and services are fully accessible. It should provide information what people can do when they run into accessibility issues and how you plan to remedy them. When you deploy new features that you know might not be fully accessible, make sure to update your accessibility statement.
- Follows content guidelines
Making content perceivable and understandable has an enormous impact on accessibility. If you have a content style guide that includes guidance on accessibility, it can help you prevent issues. The Readability Guidelines project is a great resource when you don’t have any yourself.
These are just four examples of what you can include and they will help you cover the basics of accessibility.
The best way to make you products and services truly accessible, is by including disabled people in every step the design process. Including accessibility in your Definition of Done will make your products a lot more accessible.