Why accessibility should be built from lived experience

There is a particular kind of accessible product that passes every audit and still fails the people it claims to serve. It has the right ARIA roles. Its color contrast clears the ratio. A screen reader can technically reach every control. And yet using it feels like navigating a building where every door has a ramp, but the ramps all lead to the wrong room.

I have used a lot of those products. So have most disabled people I know. And the gap between technically accessible and actually usable is where I have spent most of my working life.

The checklist is necessary and not sufficient

I want to be careful here, because the checklists matter. WCAG, semantic HTML, focus management, contrast ratios — these are not bureaucracy. They are hard-won, and skipping them locks people out in measurable ways. I would never argue against them.

But a checklist describes the floor, not the experience. It can tell you that a button is reachable. It cannot tell you that reaching it requires fourteen tab stops through a navigation menu that should have been skippable. It can confirm an image has alt text. It cannot notice that the alt text says "image" and tells a blind user nothing.

The checklist measures the presence of accessibility features. Lived experience measures whether the thing actually works when a real person, with a real body, is trying to get something real done.

What lived experience actually changes

When you build from lived experience, the questions change. You stop asking "is this compliant?" and start asking "what is this person actually trying to do, and what is standing in their way?"

That reframing produces different software. A few things I have learned only by paying attention to how people actually use what I build:

• Speed is a feature, but the wrong kind of speed is a barrier. An assistant that acts instantly can be terrifying if a wrong action is costly and hard to undo. For many users, a confirmable, reversible, slightly slower flow is far more usable than a fast one.
• Consistency beats cleverness. A predictable interface that does the same thing every time is worth more than a delightful one that surprises you. Surprise is a luxury for people who can recover from it cheaply.
• The edge case is often the whole point. The person with tremor, the person using a single switch, the person who fatigues after ten minutes — in mainstream design these are edge cases. In accessibility, they are the design target.

None of these show up on a compliance report. All of them decide whether someone keeps using the tool or quietly gives up.

"Nothing about us without us" is an engineering principle

The disability rights movement gave us the phrase nothing about us without us. It is usually quoted as a matter of ethics and representation, and it is that. But I have come to read it as a practical engineering principle too.

If you build assistive technology without disabled people in the room — not as testers at the end, but as the source of the problem definition at the beginning — you will build for an imagined user. And the imagined disabled user is almost always more capable, more patient, and more uniform than real people are. You will optimize for a person who does not exist, and real people will pay for the difference.

The fix is not complicated to describe, even if it is demanding to practice: treat lived experience as your primary source of truth. Above your intuition. Above the spec. Above what would be elegant to build.

Where this leaves me

I build differently because I have been on the other side of the screen. I know what it feels like when a tool assumes a body you do not have. That knowledge is not a credential I can put in a document. It is the lens I build through.

So when I start a project, I do not start with the framework or the architecture. I start with a person and a barrier. The technology is just how I get them past it.

That is the whole job, really. Everything else is implementation.