One of the popular questions that comes up when asking people to do accessibility work, in particular fixing broken things, is “do we have any metrics to justify that?”
On the face of it, it’s a fair question. But I’m going to argue that it’s not a fair question, or the right question.
The short version:
- we don’t apply this requirement to other aspects of design and development;
- doing this work helps more than just people with disabilities;
- framing accessibility as a separate part of the work is a misunderstanding of humans in the world.
Is it a fair question?
No. In fact I believe that, somewhat awkwardly, the question is ableist in its framing. Let me expand on that a bit.
One way to test if something is a fair question is to apply it to something similar to see if we’re applying a double standard.
In this case, we could apply the “do we have any metrics to justify that?” to other aspect of the product. Some other areas we could compare: usability, security, writing tests. In these areas it seems to be more evident that it’s worth working on them. It seems more evident that it’s just part of doing good work. We don’t ask for proof before doing the work.
- Before applying usability principles and heuristics to a design, we don’t ask “do we have any metrics on how many people will find this difficult to use?”
- Before checking for security holes, or before fixing any security bugs we find, we don’t ask “do we have any metrics on how much we get hacked?”
- Before writing tests, we don’t ask “do we have any metrics on how many bugs this code will have?”
We know that these things are worth being a little pro-active about. We know that these are just part of the day-to-day work of making a quality product. Accessibility is the same, even though we may not immediately realise it.
Privacy
For metrics on people with disabilities there’s also a privacy concern. How are we gathering these metrics? Is it any of our business what disabilities someone might have? What if someone chooses, quite fairly, not to disclose their disability?
Is it the right question?
No. Accessibility is just part of the day-to-day work of making a high quality product. It’s not something to add on. It’s not something separate: whether we consider accessibility or not, our designed and built product with have some level of accessibility.
A good question is: do we want people with disabilities to be able to use our product? If the answer is no, we might want to give a Hard Stare and discuss that bit further.
Another good question is: who else will these changes help, apart from people with disabilities. That could change the question to other (also kind of bad) questions. Such as: do we have any metrics on people who…
- use the keyboard?
- use voice control or a voice assistant like Siri?
- are older?
These people might not identify as disabled, but will benefit from “accessibility features” like:
- keyboard compatibility;
- accessible names on form elements;
- good colour contrast and responsive content.
Prioritisation
If we want to use the metrics to prioritise, that’s a bit better. But we still need to be careful.
If we find ourselves in a situation where we’re prioritising new features instead of making existing features work for everyone, that seems a bit wonky.
- It’s not good for business: customers won’t be interested in customisable invoice template if they can’t create invoices in the first place.
- It’s not good for the brand: it’s not a good look to be seen deprioritising inclusion.
- It’s not good for legal risk: we could be sued for making an inaccessible product.
Conclusion
The best way to approach this is to understand that accessibility is part of the day-to-day work of making a high quality product. It’s not extra or additional. If we currently have extra work to make it accessible, it’s because our processes, beliefs, and behaviours need updating. That’ll mean we make fewer a11y mistakes in the future.