Accessibility Testing: Four Tips for Doing It Right

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:

 

About Melissa Tondi

Melissa Tondi has spent most of her career working within software testing teams. She is the founder of Denver Mobile and Quality (DMAQ), board member of Software Quality Association of Denver (SQuAD), and Director of Quality Engineering at EMS Software, where she assists teams to continuously improve the pursuit of quality software – from design to delivery and everything in between. In her software test and quality engineering careers, Melissa has focused on building and organizing teams around three major tenets – efficiency, innovation, and culture – and has created the Greatest Common Denominator (GCD) approach for determining ways in which team members can assess, implement and report on day to day activities so the gap between need and value is as small as possible. LinkedIn Profile
This entry was posted in  All, Other, Planning for Quality, Test Planning & Strategy and tagged , , , , , , . Bookmark the permalink.