Oh no!

It's not a feature, it's a bug.

The Fire Girl meme with The text: Well, It's not a feature, it's a bug added on top of the “Disaster Girl” Meme. This meme is a picture of a little girl smiling devilishly into the camera in front of a burning house as if having caused the fire herself.

During my biweekly meetings with the accessibility committee, we discussed our challenges in prioritizing accessibility topic in our daily work.

For instance, the design team must justify any improvements by creating use cases to facilitate the prioritization and evaluation of feature development. That is the regular way of doing things internally, which is a good thing.

However, in the context of accessibility, it's nearly impossible to craft use cases for three main reasons:

  1. We lack the ability to target our users based on motor or cognitive difficulties experienced during product usage, making it challenging to extract precise usage data.
  2. From a legal standpoint, we are not authorized to request or collect this information due to privacy and medical confidentiality concerns.
  3. The majority of people with disabilities are not our users because they are excluded due to limited access.

So, how can we create use cases with pieces of information we do not possess?

We have decided to shift our narrative.

When discussing accessibility, we commonly refer to accessibility improvements, features, or issues. This terminology creates additional obstacles, whether they are conscious or subconscious when evaluating accessibility in sprints.

This vocabulary implies that we need to add something extra, enhance something invisible, or address a problem that we cannot easily verify. This creates a barrier to better accessibility. In everyone's mind, there's a sense of needing to do more, providing additional support for an underrepresented and marginalized population.

While all of this is considered true for most people, I believe that altering our vocabulary could help us break free from this detrimental internal dynamic and give more room for accessibility improvements.

The word "bug" power.

The power of the word "bug" in our accessibility initiative is underutilized. Why don't we label these issues as accessibility BUGs? Have you discovered a bug? There's no need to negotiate – a bug causes errors in our products, and it is an absolute blocker that must be urgently resolved.

We collectively need to move away from this labor-centric vocabulary. We should present things differently. We have BUGs that require fixing. If there were a BUG only in Safari, we wouldn't need to search for usage figures. A BUG is a blocker; we must eliminate this obstacle.

Let's bring our accessibility bugs to the company's attention and create BUG tickets.

We decided to conduct testing and create tickets in Jira. We should generate as many tickets as possible, provide comprehensive descriptions, and explain how developers can resolve and test them.

In the next post I will cover.

  1. The Anatomy of an Accessibility Bug Ticket.
  2. The effect of "it's a bug" has on the prioritization of accessibility issues.

Thanks for reading this

If you want to discuss this article, feel free to reach out to me (the link opens a new tab). I'd be happy to hear from you.

🤘