Solve for One, Help Everyone
Accessibility as a design method, not a box to tick
The most useful thing I ever learned about accessibility is that it is really a research method wearing a rulebook. When you design for a person at the edge of your assumptions, you find out what your product secretly depends on. Those hidden needs are almost always what makes it annoying for everyone else too.
Microsoft's inclusive design work names the trick clearly. Take one ability, look at who gets shut out, and you find three groups: permanent, temporary, and situational. One arm. A broken wrist. A new parent holding a baby. The permanent group is small. The situational group is everybody, sooner or later.
Designing for inclusion begins with recognizing exclusion.
The curb cut effect is real and measurable
Start with the kerb. A dropped kerb, that little ramp cut into the pavement, was fought for by wheelchair users. Look who uses it now. The parent pushing a pram. The traveller dragging a suitcase. The delivery worker with a trolley. The kid on a bike. It was built for one group and it quietly serves everyone. That is the whole idea in one picture.
The other stories are just as real, even though people assume they are made up. Closed captions were required for deaf viewers. Now hearing people use them far more, watching in a noisy bar or a silent office. The typewriter came partly from a machine built so a blind countess could write clearly. OXO Good Grips started because a designer's wife had arthritis, and became a kitchen-tool empire.
The pattern is steady enough to have a name: the curb cut effect. It works for a simple reason. People at the edge cannot paper over a bad design with extra effort. They show you the flaw cleanly. Average users hide it by adapting, then quietly leave.
| Built for one group | Designed for | Mainstream benefit |
|---|---|---|
| Curb cuts | Wheelchair users | Prams, trolleys, suitcases, delivery carts |
| Closed captions | Deaf and hard of hearing | Anyone in a loud bar or a silent office |
| Voice control | Limited mobility and dexterity | Driving, cooking with wet hands, dictation |
| High contrast | Low vision | Every screen read in direct sunlight |
Why the effect happens
The curb cut effect is not luck and it is not generosity. It is a property of how constraints act on a design. When you design for someone with a hard limit, you are forced to strip out ambiguity, and stripped-out ambiguity is exactly what helps everyone else.
The reason sits in how different people meet a vague design. An average user hits an unlabelled icon, a low-contrast label, a button that could mean two things, and quietly copes. They squint, they guess, they hover to check, they shrug and move on. Because they cope, they never complain, so the flaw stays invisible to the team that shipped it. Nobody files a bug for a thing they managed to tolerate.
A person at the edge cannot cope, and that is the whole value of them. A screen reader reaches the unlabelled icon and can only announce button, so the task stops dead. The ambiguity the average user swallowed becomes a wall. The edge user is not a special case you are kindly accommodating. They are an instrument that makes hidden ambiguity loud enough to hear.
Fixing it for them means naming the control, raising the contrast, ordering the focus, saying plainly what a tap will do. Every one of those is just clarity, and clarity is what the coping majority quietly wanted the whole time but never put into words. The dropped kerb removes a decision, step up or not, for the wheelchair user. It removes the very same decision for the traveller with a suitcase, who could have managed the step and is still glad not to have to.
| A vague design detail | Average user | User at the edge |
|---|---|---|
| Icon button with no name | Guesses from the picture | Screen reader says only button |
| Grey label at low contrast | Squints and reads it anyway | Cannot read it at all |
| Unclear focus order | Reaches for the mouse | Gets lost with no way back |
Where the actual failures are
WebAIM has checked the top million home pages every year for years, and the results barely move. Most pages have failures a machine can detect. And the same few problems cause nearly all of them.
Look at that list again. Not one is a hard engineering problem. They are all choices someone made in a design file: grey text on white because it looked elegant, an icon button with no name because the icon seemed obvious. So the fix belongs at the source, in the building blocks, not in a clean-up sprint later.
What I build into the system
- Starts from a checklist near the ship date
- Bolts accessibility tags on at the end
- Counts success as an audit score
- Treated as a cost to keep small
- Fixes rot back after each release
- Starts from a person at the edge
- Builds names, focus, and contrast into the block
- Counts success as friction removed for all
- Treated as a research method
- Fixes hold, because the whole problem is gone
- 01Contrast checks in the build. Colour pairs are checked automatically against the WCAG 2.2 AA standard. A change that adds a failing combination cannot merge. That kills the whole problem for good, instead of fixing it again and again.
- 02Focus as a designed state. Not the browser default, not removed: a real, designed ring in the system, visible on every clickable thing, tested by tabbing through the page without touching the mouse.
- 03Names before labels. Every clickable element gets a proper name at the component level, so a nameless icon button is impossible to build rather than merely frowned upon.
- 04Reduced-motion versions. Every animated block ships with its calmer version in the same file. If the calmer version is missing, the component is not finished.
- 05Target size. WCAG 2.2 added a 24 by 24 pixel minimum. Bake it into the block's padding so nobody has to remember.
The case that lands with executives
Ethics should be enough. Often it is not, so keep the rest of the case ready. Over a billion people worldwide live with a disability, by WHO's estimate. Legal risk is climbing fast. The European Accessibility Act came into force in June 2025 and covers a wide range of consumer digital products sold in the EU. And accessible markup is the same markup machines read, which matters more than ever, because screen readers and AI agents see your page through the exact same layer.
That last point gets too little attention. An agent using your product for someone relies on accessible names, roles, and states. A product a screen reader cannot read is a product an agent cannot read. Accessibility has quietly become a requirement for working with machines at all.
The business case is real, and it is a trap
There is an honest problem buried in everything I have said so far. The curb cut effect is the argument people reach for to sell accessibility to a business. Do it because everyone benefits, because it widens your market, because it lifts conversion. All of that is true. It is also fragile, because it quietly accepts a dangerous premise: that accessibility has to pay for itself to be worth doing.
The moment you win the room with a revenue chart, you have agreed to lose it the day the chart points the other way. If some fix helps a group too small to move the numbers, the same logic says skip it, and you have handed over the exact tool needed to justify exclusion. The curb cut effect is a happy fact. It is not a foundation.
The foundation is plainer than a spreadsheet. People have a right to use the things that run their lives: their bank, their government, their doctor, their kids' school. That does not stop being true when the addressable market is small. So I keep the numbers ready for the meeting, and I do not let them become the reason. The business case is a good thing to bring to a room. It is a bad thing to believe.