Why accessibility bugs are a good thing and how to handle them

Cartoon of individual looking at computer pondering if something is a bug or a feature

Hint: “fix the bug” is probably the least important item on the list

It is incredibly common when I do accessibility podcasts, I am asked, “what does accessibility success look like to you?” I, perhaps oddly, count beginning to get accessibility bugs reported as a sign of accessibility success. Accessibility bugs are:

  • a report of an issue;
  • by a user with a disability, generally using assistive technology;
  • who got far enough *INTO* the product to find a bug;
  • and cares enough to report it to you for free, so they can continue using your product/service more easily.

Once you have accepted that in software, especially SaaS software, there is no such thing as “zero defects” (despite what Philip Crosby might claim), what’s not to like as an accessibility manager about that series of statements?

Once you have reached this level of accessibility success, here are my thoughts about what successful accessibility programs do and don’t do.

Things accessibility managers should NOT do

There are a few things that accessibility managers should try to avoid doing concerning accessibility bugs.

1. Do not make it hard for the public to find you

This article I wrote about two and a half years ago identifies all the places from the customer’s perspective they might investigate to report an accessibility issue. TL; DR:

  • Have and monitor an accessibility@companyname.TLD email address.
  • Make friends with the people in charge of social media and customer support so if accessibility issues cross their paths, they know who to forward them to.
  • Put a bug reporting form on your accessibility statement HTML page.

2. Do not deny the bug exists or deprioritize the bug report

When users do find you, ignoring their bug report does not make it go away. Neither does deprioritizing bug reports so they never make it to the top of the backlog to get addressed. Accessibility bugs need to have a prioritization system equivalent to functional bugs. A P0/critical accessibility bug (where a user with a disability is blocked from completing a transaction) should be treated similarly to any other P0/critical bug.

3. Do not immediately start solutioning

If you have a script that says to start by telling the user to reboot their device, please drop it in the nearest recycling receptacle. Accessibility bugs require a substantial amount of information gathering (see the following section which describes this in detail) before you start to look for workarounds.

4. Do not center yourself/the accessibility team/the organization

This call needs to be about the customer and the inconvenience they have experienced, not about you, the accessibility team, or the organization.

5. Do not end the conversation without identifying the next steps and timeline

Establishing the next steps and executing them is critical to retaining customer trust for all unhappy customer contacts with an organization.

Things TO do when you get an accessibility bug report

Now that you know what not to do, here is a list of things TO do

1. Do acknowledge responsibility and apologize

“I’m truly sorry you experienced this issue, I will take care of it,” is what your users want to hear.

2. Do offer an alternate path to the transaction

I saw a post yesterday that had gone semi-viral flaming a well-known, 150+ year-old retailer regarding an inaccessible process that led to the disabled customer losing a 25 % discount on their purchase.

  1. That approach is an excellent way to lose future business from that customer and everyone who read their flame, and;
  2. Unfortunately, that approach also increases your chances of litigation because the user can prove that they were harmed financially due to the lack of accessibility. This user is not an “ADA tester. ” They are a real user who can demonstrate actual harm. Courts have repeatedly stated that this set of facts is something that is incredibly important.

Repeat after me: If a disabled user can’t do an online transaction because of an accessibility bug, the person handling the bug needs to be able to put through the transaction for them with the SAME ONLINE DEAL they would have gotten if they hadn’t run into the accessibility bug. The customer needs to get that offer a) easily, preferably without having to ask for it, and b) without being made to feel like the organization is doing the customer a favor.

Don’t hand a plaintiffs’ firm a dream plaintiff. Plan as part of your customer support program to make every disabled customer “whole,” which is lawyer-speak for “give them the deal they would have gotten if they didn’t have a disability.”

Recognize that the customer who reported the bug is doing you a favor by not reporting your organization to the DOJ or one of the many litigation firms that would be happy to sue on their behalf.

3. Do gather as much information as possible

Many accessibility bugs are particular to the user’s environment. They can be device, operating system, browser, and assistive technology-specific, and even sub-specific in terms of the version number of the hardware or software within each of those four categories. I’ve seen assistive technology bugs that only happen on old or plus-sized devices or on lower memory mobile devices/tablets/Kindles. If you aren’t collecting this information, you are substantially reducing the chances that you will ever be able to find the source of the issue, fix it, and prevent it from happening again.

4. Do ask the user their preferred mode of communication and use it.

Some users prefer voice, others prefer email. You won’t know unless you ask, and your user will thank you for using their preferred mode of communication.

5. Do actively listen

Active listening in customer service means being focused on what the customer is saying and how they are saying it, combined with responding in a manner that validates what they’re saying. Some activities associated with active listening-based conversations are:

  1. Not interrupting;
  2. Demonstrating concern for the customer’s bad experience;
  3. Paraphrasing back what the customer is saying, showing attention to detail and understanding;
  4. Asking questions;
  5. Avoiding arguing, becoming defensive, or laying blame on the customer.

6. Do de-center yourself/the accessibility team/the organization

Part of active listening is making the conversation about the user and not the organization. This is a process called decentering. The organization may have a world-class accessibility program. However, the bug reporter does not want to hear about that, because all the right things that were done didn’t prevent them from being blocked by the bug they are reporting.

7. Do involve the right people to solve the issue and hold them accountable

Clearly, fixing the bug is essential. But note we don’t even get to that until step 7 of my “What to do?” list. Likely you will not be the person fixing the bug, so it is important to make sure that:

  1. The bug gets entered into the defect tracking system;
  2. The bug gets scheduled to be fixed, and;
  3. One and two get reported back to the customer.

8. Do a root cause analysis and update the testing process

It’s not enough to fix the reported bug. You need to figure out how the bug slipped through the accessibility testing structure and modify the process, so the bug and others like it do not creep back into the product.

9. Do communicate concrete next steps to the reporter and follow-up

If you promise to contact the user in a week, contact the user in a week, even if you don’t have anything meaningful to report. “Hi, this is taking longer than we thought. We are still working on this,” is better than breaking a promise to the person who reported the bug.

It takes a lot of positive steps to build trust with a customer reporting a bug

and only one mis-step to destroy that trust

Tell the user as much as you can about who is looking at the issue, what the ETA is for resolution, and whether you will have a pre-release version where they will be able to validate that the bug has been fixed before the bug fix is released to the public.

10. Do ask the reporter if they want to be involved in future research and beta testing

You would be surprised how many people will give you a resounding “YES!” to this question. This is especially true if payment is involved but is also quite frequently true even if you can’t pay those participants.

11. Do ask the reporter to complete an ACCESSIBLE survey

The only way you will know if there is anything the user wished happened differently during the bug resolution process is to ask them. This is especially critical if you ask non-disabled users to complete service surveys. Of course, the survey has to be accessible. Many survey authoring systems can’t be used by assistive technology users. Looking at CSAT (Customer Satisfaction) and NPS (Net Promotor Scores) for your disabled customers and your non-disabled customers separately will help you identify if there is a gap between the perceived quality of your support of customers with disabilities.

Accessibility is like plumbing.

  • When an organization is doing a good job at accessibility, it frequently goes unnoticed.
  • When the organization misses something accessibility-related, and the customer needs it, broken accessibility (like broken plumbing) is suddenly an emergency.

Your (happy) customers are your most valuable asset.

Your customers with disabilities can teach you about their assistive technology, their tech stacks, how they process data, and even disability etiquette.

Stop assuming you know how your customers with disabilities will use your products. Instead, *watch* them use your products. See what barriers they run into and what workarounds they have developed from their years of experience to get past those barriers. And then get rid of the barriers! The best support call is the one that never has to be made.

And finally, don’t forget to pay your customers with disabilities for this valuable knowledge they will be sharing with you.