Accessibility Is More Than Contrast and Screen Readers

When most developers hear "accessibility," they think of a checklist: color contrast ratios, alt text on images, labels a screen reader can announce. Those things matter, and you should do them. But they're the floor, not the ceiling — the part that's easy to name and easy to audit with a tool.

The harder part doesn't show up in an automated scan. It's how much a person has to understand, remember, and hold in their head to use what you built. Call it cognitive load. It's the accessibility problem I think about most, because it's the one I live on the other side of.

I build on an unreliable energy budget. On a low day, working memory is the first thing to go. And here's what that taught me: the things that make software usable when I'm running on empty are the same things that make it usable for someone anxious, distracted, in pain, grieving, exhausted, or simply new. Designing for a depleted person isn't a niche. It's designing for everyone, on the day they most need it to be simple.

What this kind of accessibility looks like

• Resumability. Can a person leave in the middle and come back without losing their place or their work? Interruption is the normal case, not the exception — a kid, a phone call, a wave of fatigue. Software that punishes you for stepping away is software that assumes a life you might not have.
• Plain language. Every sentence a person has to decode is a small tax on attention. Clear words, and honest error messages that say what happened and what to do about it — that's an accessibility feature, not a copywriting nicety.
• Predictable navigation. When things sit where you expect and behave the way they did last time, the interface stops demanding thought. Novelty and cleverness in a layout are expensive; they make the user re-learn instead of act.
• Forgiving workflows. Can you undo? Recover a draft? Fix a mistake without starting over? A system that treats every error as permanent forces a level of vigilance a tired person simply doesn't have to give.
• Fewer decisions. Every choice you put in front of someone spends a little of their attention. Sensible defaults and one clear next step are a gift to a person whose capacity to decide is already spent.

Why I take it personally

I'm building a product for people in the middle of rebuilding their lives — after a loss, an illness, a career ending, the structure falling out from under them. If there's a group I cannot afford to design for on their best day, it's that one. They are, almost by definition, arriving depleted.

So the standard I hold is simple, and it's the same one I hold for my own code: it has to work for someone running on very little. Not the confident, rested, fully focused user the demo imagines — the real one, on the day the interface is the last thing they have patience for.

The reframe

Automated contrast checks and screen-reader labels are necessary, and I'm not waving them off. But they let you pass an audit while still shipping something exhausting to use.

The deeper question doesn't have a linter: how much does this ask of a person who has very little to give right now? Answer that one honestly and you're not just building for people with disabilities as a separate category. You're building for every user — because every user eventually has a bad day, and the software that respects that is the software they'll still be able to use when they need it most.