If you are feeling a little overwhelmed by the extra effort involved in delivering accessible software, don’t be dismayed. Here are some helpful tips to keep in mind.
1. Embed Accessibility Testing
The purpose of the first round of guideline verification is to document defects and create a backlog of issues that need to be addressed. By embedding the accessibility testers in the project team, you will have the benefit of seeing the burndown of their work on a daily basis, and you’ll get that information to the team in the most efficient way possible. The quicker the information flow, the more time to resolve the issues.
2. A Bug Is a Bug
The defects that come as a result of the guideline verification should be triaged the same way as all other issues your team encounters. There is a tendency to treat accessibility issues differently, but resist the urge—a bug is a bug.
If there is a sound reason to separate them for reporting purposes, and if you have the ability to configure your defect management tool, create a category titled Accessibility and include an option to designate the severity, which could be correlated with the impact on Level A, AA, or AAA compliance.
3. Managing Defects
All defects should have a priority classification. If an accessibility defect is not serious enough to affect your level of conformance, fixing it can wait.
Depending on how many accessibility defects are reported during guideline verification, your product owner may want the ability to run a separate sprint to focus on accessibility. If the accessibility defects are prolific, consider handling them the same way your organization handles technical debt.
Once your teams understand that conformant code is required and how to implement coding practices that support accessibility, consider including the verification as part of your “done” definition.
4. The Accessibility Statement
The best way to tell your users you have incorporated accessibility features is an accessibility statement. The statement exists not just to tell users at which level of conformity your site has been verified, but also to let them know that you’re committed to providing a great experience for all users.
During initial verification, your product may not conform to its intended level. The accessibility statement also allows you to be transparent with what you’re doing to address known defects.
You might find the World Wide Web Consortium’s Web Content Accessibility Guidelines and this accessibility statement generator site helpful as you prepare your own accessibility statement. Keep in mind that it should include:
- The level of conformity to which it was tested (Level A, AA, AAA, or other)
- The level of conformity to which it complies
- The exceptions (defects) preventing it from conforming to its intended level
- Contact information or steps to report accessibility issues
These tips will allow for an efficient and long-term accessibility testing initiative and result in a happy experience for all users.
For related reading, check out:
