🥔 Potato Code
One of the best developers I know deployed a hilarious mistake to production.
Separate is Not Equal
My friends have heard me say before that with the European Accessibility Act, I've seen people react with all 5 stages of grief:
- Denial, "Surely, our product is exempt."
- Anger, "The EAA is just a money-grab, that's all."
- Bargaining, "Well, what about internal tools? I don't have to make those compliant, right?"
- Depression, "This is going to take forever to fix!"
- Acceptance, "Wow, my product is easier for everyone to use, not just blind people!"
These quotes are real reactions from real people. It doesn't seem to matter what role, project, team, company, etc; the EAA is a big-ask for almost everyone.
I totally get it. For most engineers, no matter how senior, this is the first time in their careers they've had to care about accessibility. That's a scary place to be, and I have a lot of empathy for that.
In case you aren't familiar with the EAA, in short: As of June 2025, any product distributed in the European Union has to be considered "accessible" in order to avoid fines or sanction.
As we learn what that means for our products, I want to offer some guidance on avoiding two common fallacies. I hope by the end, you will see that the EAA is a blessing on the world for everyone, not just those who "need" it.
The fallacy of separation
Some years ago, I heard a well intended, but misguided comment: "Well since our product is so inaccessible, why don't we just build a simpler version for screen readers, and then direct people to that when we detect they are using a screen reader."
And my friend isn't the only one to come up with this "solution". I've heard this sentiment at conferences, lunch conversations, all over. It's a surprisingly common reaction.
Other than being a maintenance nightmare, there are a few things fundamentally wrong with this approach:
- Not all screen reader users are blind. Many of them are sighted or partially-sighted.
- That "simpler version" is probably missing functionality that some users would like to use.
- What are the odds both versions are going to receive the same level of testing, updates, and support?
History has taught us that separate is never equal. As soon as we start treating any group of people differently than everyone else, we risk crossing over into discrimination. (It's exactly why the browser deliberately prevents the ability to collect that kind of telemetry. There's no way to know what assistive technologies your users are using, if any.)
The purpose of the EAA is to help close the ability-gap found throughout society. It doesn't care if the cause is systemic, accidental, or deliberate. The EAA's only goal is to convince entities within its reach to think twice about exclusion and separation.
This is the crux of inclusive design: to build your product so that everyone, regardless of personal physical ability, can use it. Not individual products for each "kind" of user. Not products that exclude certain users on the basis of uncertain ROI. But rather, one same product that works for everyone.
The fallacy of limited scope
When making a product accessible, many people only consider the effect for customers with disabilities. They tend to think that only those users will benefit from greater support.
In my experience, this is almost never the case. In reality, what happens is:
When you make a product usable for more people, it makes it usable for even more people.
Accessibility is a multiplier, not an adder. It provides the polish all your users will benefit from. Why is this so? Because virtually all of your users will experience a disability (whether temporary or permanent) at some point while using your product.
Have you ever held a baby while trying to do something on your computer or phone? Have you tried to watch a video on a crowded bus, but forgot your headphones? Have you ever tried to reply to an urgent message while driving? These are all examples of a temporary disabilities. The list goes on.
- You designed your product to work for users with motor disabilities: Good, now it works for parents on the go.
- You put captions on your videos for the Deaf: Excellent, now your boss can review the content during her bus ride to work.
- You enabled text-to-speech and dictation for people with dyslexia: Awesome, now everyone can benefit from it.
The electric toothbrush was designed for users who struggle with dexterity. But your dentist knows that it's way better at doing its job than a manual brush. You've probably never considered it as an "assistive technology", it's just the better toothbrush.
The same goes for software. When you build and design with accessibility in mind, you create a product everyone can use. It's just the better product. And the historical ROI on quality products should speak for itself.