Why accessibility is the most honest quality criterion I know
When building an application, you spend a lot of time thinking about usability. You arrange things, rename them, move buttons around — and ultimately design everything the way you believe works best for the user. In my case, that application was Risky Business, my project risk management app.
The problem is: you are your own worst test user.
You know what the icon means. You know why that field is where it is. You understand the abbreviation because you invented it yourself.
The real stress test for a design comes from somewhere else: implementing accessibility.
The Moment Your Design Gets Honest
Working on the VoiceOver integration in particular made me think.
Suddenly, you find yourself asking questions you may never have asked before:
You quickly realize: a screen reader doesn’t sugarcoat anything.
It reads what is there.
And if all it finds is “Button,” then that’s exactly what it says: “Button.”
And the user knows exactly as much as they did before.
What You Discover
Quite a lot, actually — including things you probably would never have noticed otherwise.
Icons without meaning.
The icon seemed perfectly self-explanatory visually. But VoiceOver announces it as “Button.” End of information.
Values without context.
Visually, “4” may be perfectly clear because there is a label next to it and a scale underneath. Audibly, “4” is just a number floating in space.
“4” needs to become:
“Probability of occurrence, 4 out of 5.”
A reading order nobody intended.
Visually, we read columns, groups and blocks. A screen reader follows the underlying structure — and mercilessly exposes whether that structure follows the logic of the content or merely the visual layout.
States that nobody announces.
Selected, expanded, disabled, loading: visually, everything is obvious.
Audibly: silence.
Labels you can’t explain yourself.
Nothing exposes vague terminology quite as effectively as trying to turn it into a meaningful accessibility label.
If I can’t explain in one sentence what an element does, then the label isn’t the problem. The element is.
And then there are the really interesting cases.
The heart of Risky Business is a 5×5 risk matrix. Visually, you understand it in a second: color, position, done.
With your eyes closed, however, it is initially just a grid of 25 cells.
At that point, another label isn’t enough. You have to think about the information architecture itself:
What is the actual message here, and how do I communicate it without relying on the visual representation?
That isn’t an accessibility problem.
It’s a design problem that accessibility finally made visible.
A Different Level of Quality Assurance
That’s the key point.
Accessibility isn’t functional QA.
Functional QA asks:
“Does the application do what it’s supposed to do?”
And the answer is usually green or red.
Accessibility asks something different:
“Is the application understandable without seeing the context?”
And that does something usability discussions often struggle to achieve: it makes a subjective topic measurable.
“I think this is intuitive” is an opinion.
“This element is announced as ‘Button’” is an observation.
You can debate opinions endlessly.
Observations are much harder to argue with.
That’s why implementing accessibility has become one of the most revealing usability tests I know — and one of the few I can perform without test participants, a research budget or scheduling a workshop.
The Side Effect: It Gets Better for Everyone
What surprised me most was that almost every change I made for VoiceOver also improved the app for sighted users.
- Clearer terminology.
- Better grouping.
- An order that follows the content rather than the layout.
- States that are communicated explicitly.
It’s the classic curb-cut effect.
Dropped curbs were designed for wheelchair users — but they’re also used by people with strollers, rolling luggage and delivery carts.
Larger text also helps someone trying to read their phone in bright sunlight.
Good contrast helps tired eyes at 11 p.m.
Accessibility isn’t a feature for a small target group. It’s a quality attribute that happens to benefit everyone.
And Yes, There Is Also the Legal Reason
Since June 28, 2025, Germany’s Accessibility Strengthening Act (BFSG) has been in effect, implementing the corresponding European requirements.
For many digital products and services offered to consumers, accessibility is therefore no longer optional but a legal requirement — with certain exceptions, including some microenterprises and purely B2B offerings.
But for me, that’s actually the weaker argument.
The better one is simple: You end up with a better product.
Something Worth Trying
If you want to find out how good your own design really is, you don’t need a workshop.
- Turn on VoiceOver.
- Enable Screen Curtain.
- Keep the display dark.
Then try to complete one typical task in your own application.
The first five minutes are uncomfortable.
After that, you’ll have a to-do list that’s more honest than almost any review meeting.
When building an application, you spend a lot of time thinking about usability. You arrange things, rename them, move buttons around — and ultimately design everything the way you believe works best for the user. In my case, that application was Risky Business, my project risk management app.
The problem is: you are your own worst test user.
You know what the icon means. You know why that field is where it is. You understand the abbreviation because you invented it yourself.
The real stress test for a design comes from somewhere else: implementing accessibility.
The Moment Your Design Gets Honest
Working on the VoiceOver integration in particular made me think.
Suddenly, you find yourself asking questions you may never have asked before:
- Are all labels and captions actually where they should be?
- Do the texts being read aloud still make sense when you can’t see the screen?
- Can you understand the application with your eyes closed — or is it simply too complicated?
- Are all elements semantically correct? Is a button really a button? Is a heading actually marked up as a heading?
You quickly realize: a screen reader doesn’t sugarcoat anything.
It reads what is there.
And if all it finds is “Button,” then that’s exactly what it says: “Button.”
And the user knows exactly as much as they did before.
What You Discover
Quite a lot, actually — including things you probably would never have noticed otherwise.
Icons without meaning.
The icon seemed perfectly self-explanatory visually. But VoiceOver announces it as “Button.” End of information.
Values without context.
Visually, “4” may be perfectly clear because there is a label next to it and a scale underneath. Audibly, “4” is just a number floating in space.
“4” needs to become:
“Probability of occurrence, 4 out of 5.”
A reading order nobody intended.
Visually, we read columns, groups and blocks. A screen reader follows the underlying structure — and mercilessly exposes whether that structure follows the logic of the content or merely the visual layout.
States that nobody announces.
Selected, expanded, disabled, loading: visually, everything is obvious.
Audibly: silence.
Labels you can’t explain yourself.
Nothing exposes vague terminology quite as effectively as trying to turn it into a meaningful accessibility label.
If I can’t explain in one sentence what an element does, then the label isn’t the problem. The element is.
And then there are the really interesting cases.
The heart of Risky Business is a 5×5 risk matrix. Visually, you understand it in a second: color, position, done.
With your eyes closed, however, it is initially just a grid of 25 cells.
At that point, another label isn’t enough. You have to think about the information architecture itself:
What is the actual message here, and how do I communicate it without relying on the visual representation?
That isn’t an accessibility problem.
It’s a design problem that accessibility finally made visible.
A Different Level of Quality Assurance
That’s the key point.
Accessibility isn’t functional QA.
Functional QA asks:
“Does the application do what it’s supposed to do?”
And the answer is usually green or red.
Accessibility asks something different:
“Is the application understandable without seeing the context?”
And that does something usability discussions often struggle to achieve: it makes a subjective topic measurable.
“I think this is intuitive” is an opinion.
“This element is announced as ‘Button’” is an observation.
You can debate opinions endlessly.
Observations are much harder to argue with.
That’s why implementing accessibility has become one of the most revealing usability tests I know — and one of the few I can perform without test participants, a research budget or scheduling a workshop.
The Side Effect: It Gets Better for Everyone
What surprised me most was that almost every change I made for VoiceOver also improved the app for sighted users.
- Clearer terminology.
- Better grouping.
- An order that follows the content rather than the layout.
- States that are communicated explicitly.
It’s the classic curb-cut effect.
Dropped curbs were designed for wheelchair users — but they’re also used by people with strollers, rolling luggage and delivery carts.
Larger text also helps someone trying to read their phone in bright sunlight.
Good contrast helps tired eyes at 11 p.m.
Accessibility isn’t a feature for a small target group. It’s a quality attribute that happens to benefit everyone.
And Yes, There Is Also the Legal Reason
Since June 28, 2025, Germany’s Accessibility Strengthening Act (BFSG) has been in effect, implementing the corresponding European requirements.
For many digital products and services offered to consumers, accessibility is therefore no longer optional but a legal requirement — with certain exceptions, including some microenterprises and purely B2B offerings.
But for me, that’s actually the weaker argument.
The better one is simple: You end up with a better product.
Something Worth Trying
If you want to find out how good your own design really is, you don’t need a workshop.
- Turn on VoiceOver.
- Enable Screen Curtain.
- Keep the display dark.
Then try to complete one typical task in your own application.
The first five minutes are uncomfortable.
After that, you’ll have a to-do list that’s more honest than almost any review meeting.