Accessibility Is Not a Checklist. It Is a Design Constraint.
In 2025 I was part of the team that won an Apple Design Award for Speechify, in the Inclusivity category. I want to be careful about how I talk about that, because the lesson people usually take from an accessibility award is the wrong one.
The wrong lesson is that we were thorough. That we went down a list, checked contrast ratios, added labels, and got recognised for diligence.
That is not what happened, and diligence is not what wins.
The checklist is the floor, not the work
Contrast ratios, focus order, alt text, touch target sizes, screen reader labels. All of it matters and all of it is required. But a product can pass every automated audit and still be miserable to use if you cannot see the screen.
Passing means nothing is technically broken. It does not mean anything is good. You can build a fully compliant interface that takes a blind user ninety seconds to do what a sighted user does in four, and no tool will flag it, because nothing is wrong. It is just bad.
The difference between compliant and good is the same difference as between a building with a ramp bolted to the side and a building where the entrance simply works for everybody. Both pass inspection.
Constraints make the product better for everyone
This is the part that convinces sceptical stakeholders faster than any moral argument, so I lead with it now.
Designing for someone who cannot see the screen forces you to make the structure of the product explicit. What is the hierarchy actually? What is this control for? What happens after I press it? Those are not accessibility questions. They are design questions that most teams never have to answer clearly because sighted users can paper over vagueness with visual guessing.
Every time I have designed properly for a screen reader, the visual version got better too. The labels got shorter and truer. The flow got fewer steps. Things that had been ambiguous had to be decided.
Captions help people in loud trains. Large touch targets help people with one hand full. High contrast helps everyone outdoors. This is not a stretch, it is the ordinary result of designing for the hardest case.
The thing that actually changes the work
Use the product the way the person you are designing for uses it. Not a simulation, not a plugin that greys out your colours. Turn the screen off and use your app with VoiceOver for twenty minutes.
It is humbling in a way that no report is. You find out that your beautiful icon button announces itself as "button", that your modal traps focus in the wrong place, that your loading state says nothing at all so it just sounds like the app died.
None of that is on a checklist. All of it is obvious in four minutes of actual use.
Where it should sit in the process
At the start, or it does not really happen.
Accessibility added at the end is a repair job, and repair jobs get cut when the deadline moves. Accessibility decided at the start is just how the thing is built, and it costs almost nothing extra because you never built the inaccessible version in the first place.
The expensive version is always the retrofit. Teams that complain about the cost are usually describing the cost of having deferred it.
Why I care about this one
Most of design is you telling people the work is good. An award is the part where somebody else says it, and in this case the somebody else was Apple.
But the reason that project matters to me is not the award. It is that the people it was built for could suddenly read things they could not read before. That is a very literal, very unglamorous outcome and it is the only kind that has ever made me feel like the job was worth doing.