7 Tenets of Accessibility Bug Reporting

How to help teams prioritize accessibility issues effectively.

Most people don’t want to actively deny access to disabled customers. More often, digital accessibility is seen as a low relative priority, compared to other projects and tasks. Presenting legal or emotional ultimatums may create initial movement, but they’re not sustainable motivators and they can breed resentment towards an accessibility practice.

Drawing of a character pondering before his shadow.

We take a different approach. We practice “Show don’t Tell”, and give teams the information to determine relative priority themselves.

I’ve been impressed with the creativity and engagement we see with this approach, so I’m capturing some basic tenets here, specific to reporting digital Accessibility issues.

Focus on Conversions

Focus remediation on user journeys that lead to conversion.

When you’re looking for issues, it’s tempting to go for lots of easy wins across different, unrelated parts of an application (e.g. adding alternative text to images). Instead, focus on user journeys that lead to conversion. Your customers are there for a reason, and usually that reason aligns with your bottom line. Make it possible for them to accomplish their goal.

For example, if your customer can’t complete a purchase, they’ll be more frustrated than (for a screen reader user) a poorly described image on the home page. You’re also more likely to get buy-in from product managers and leadership when you focus on conversion.

Describe Human Impact

Describe an issue’s impact in human terms. Include customer feedback if you can.

Standards and rules are useful for identifying issues and assessing solutions, but they don’t inspire. Teams care about people, in either emotional or business terms (customers). Compliance talk also invokes the specter of lawsuits. That can be useful in leadership conversations, but not in the context of bug reports.

Describing impact also helps teams to decide on relative priority of the issue against other issues in their backlogs. This brings us to the next point.

Let Teams Prioritize

Give teams the information they need, then trust them to be professional and organized.

When you describe issues in terms of customer impact and severity, you then trust teams do their jobs to prioritize. It’s up to the Product or Engineering Manager to decide on relative priority of the issue.

Have a conversation with the team’s PM before adding an issue to their backlog, and add it to the Icebox or lowest priority. Follow the ticket and keep an eye on activity. Set a reminder for yourself to followup if there’s no movement on the issue, but assume a team is professional and organized. If they’re not, that’s an issue beyond the specifics of accessibility.

Recommend Solutions

Give technical guidance, but avoid prescribing solutions.

Trust engineers and designers to learn and ask questions. It’s their job, and also the best way for a team to grow their accessibility knowledge, and you may be surprised by the creativity and ingenuity of solutions.

Attention, not Assignment

Bring attention to an issue, then let teams decide how to assign.

When you let people self-assign accessibility issues, they’ll be more engaged (and accountable). You don’t know what other teams’ priorities are, or what an individual’s personal situation is. Instead of assigning, @ mention the owner of the backlog (PM or Engineering Manager) to get attention on the issue. Use this as an opportunity to communicate your opinions on priority and required expertise, then let them decide.

Automate

Automated systems lighten your load and make it less personal.

Use tools that automate accessibility testing. The feedback is immediate, and a comment from a bot carries less risk of being taken as a personal critique. We built AccessLint to comment on Pull Requests in GitHub automatically.

Celebrate Success

Focus on wins and celebrate success.

Drawing of two characters jumping for joy.

Accessibility remediation is a long-haul, and you’ll need to sustain motivation and investment. You can do this by mentioning a team’s work in a monthly Accessibility Changelog, and where appropriate celebrate individual contributions (ask them first if they want to be publicly recognized).

In summary, document issues comprehensively, describe their impact and severity, and then let teams do their jobs. Stay engaged, follow up, and answer questions when asked, but ultimately trust the professionalism and organization of your teammates to address issues.

AccessLint hooks into GitHub and tells you when you code has accessibility issues. Install AccessLint in GitHub for free.