Accessibility Is Architecture, Not a Checklist
I’m Leon Shelhamer. I’ve written before about why I care about accessibility - the short version being that it took our industry twenty years and a pandemic to start taking it seriously. This post is about something narrower and more useful: how you actually build an accessible site, and why almost everyone who claims to is doing it backwards.
The checklist trap
Most “accessible” sites were built like every other site and then had accessibility bolted on at the end - an automated scanner the week before launch, a panicked patch of whatever it flagged, and a green checkmark. That’s the checklist trap, and it’s why so much of the web is technically compliant and practically unusable for the people the rules exist to protect. Automated tools catch maybe a third of what actually matters. The rest - whether a keyboard user can reach every control, whether focus lands somewhere sane after a modal opens, whether a screen reader announces the page in an order that makes sense - none of it shows up in a scan. It shows up in the architecture, or it doesn’t show up at all.
Where it actually lives
Accessibility is decided when you choose your markup, not when you audit it. A page built from semantic HTML - real landmarks, headings in the right order, buttons that are actually buttons - is accessible almost by default. A page built from nested divs with click handlers bolted on is something you then spend weeks faking accessibility back into with ARIA. And ARIA is a scalpel, not a bandage: the first rule of it is that you don’t use it if a native element would have done the job.
When I build a site, the accessibility decisions are the engineering decisions. One h1 per page, because the document outline should mean something. Full landmark structure, so assistive tech can navigate by region. A visible focus ring, because a keyboard user who can’t see where they are is locked out. Motion that respects prefers-reduced-motion, because for some people animation isn’t delight, it’s nausea. A dark mode that holds its contrast in both themes. None of that is a remediation pass. It’s just how the thing gets built in the first place.
Why I say AA and not AAA
You’ll notice I claim AA, not AAA, and that’s deliberate. Full AAA across a real, content-rich site is genuinely hard, and in places it fights usability - the contrast rules alone can box you out of an entire brand palette. AA, done honestly and all the way through, is already stricter than most sites that claim it actually meet. I’d rather build to AA and have it be true on every page than print AAA on a slide and watch it fall apart the moment someone tabs through with a screen reader on. Defensible and real beats impressive and false. That’s a rule I try to apply to everything I put my name on.
The same lesson, again
I keep landing on one idea in this work: constraints make better systems. Designing for the small screen made better websites for everyone. Designing for the machine makes cleaner software for everyone. And designing for the person on a keyboard with a screen reader - the most constrained user you have - makes a sturdier, better-structured site for everyone else too. The semantic markup that helps a blind user is the same markup that helps Google understand your page and helps the next developer read your code.
That’s why accessibility is one of my four core services and not an upsell. It isn’t charity, and it isn’t compliance theater. It’s the discipline of building things correctly, with the hardest case in mind from the start. Handle that case, and the easy ones mostly take care of themselves.
Leon Shelhamer is a senior software engineer with sixteen years of experience and the developer behind Two Eleven Jay and the managed-hosting service uphost.ly. He works in React and Vue, runs his own production infrastructure, and builds AI-augmented development workflows from upstate New York. Connect on LinkedIn.
