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

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

Authors note: Because of Medium’s refusal to address its accessibility issues for both authors and readers, I’ve moved my last three years of blogs to Substack. Please sign up there for notices of all new articles. Thank you for your continued readership and support.

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.