Accessibility is the building code of the web
Nobody admires a handrail, but you notice the building without one. A construction-minded checklist for accessible interfaces.
Nobody walks into a building and admires the handrail. Nobody compliments the fire exit signage or the width of a doorway. You only notice those things when they are missing, and by then someone has already been shut out or hurt. Building codes exist because we stopped trusting each project to remember them.
The web has the same idea under a different name. Accessibility guidelines are a building code for interfaces, and most of what they ask for maps neatly onto things a construction person already understands.
Ramps: keyboard access
A ramp means the building works for someone who cannot use the stairs. Keyboard access means the interface works for someone who cannot use a mouse. If you can reach and operate everything with Tab, Enter and Space, you have built the ramp. Native elements like button and a give you most of it for free. A div with a click handler does not.
Signage: labels and headings
A building with no signs is a maze. A form with placeholder text and no labels is the same maze, because the hint disappears the moment someone starts typing. Visible labels, headings in a sensible order, and link text that says where it goes are the wayfinding of the web.
Lighting: contrast
Poorly lit corridors are a hazard. Low-contrast text is the screen equivalent. Pale grey on white looks refined in a mockup and becomes unreadable on a cheap phone in Lagos sunshine. Check your text against a contrast tool before you fall in love with the palette.
Fire exits: error states
Every building plans for the bad day. Interfaces should too. When something fails, the user should be told what happened and what to do next, in words, not just in red. "Failed" is a locked fire door. "We could not send your message. Check your connection and try again" is a lit exit sign.
The inspector only catches so much
Automated tools like Lighthouse and axe are the building inspector. They are worth running on every release and they catch real problems. But an inspection certificate does not mean a building is pleasant to use, and a perfect audit score does not mean a site is usable with a screen reader. At some point you have to walk the building yourself.
If you want a short list to start with:
- Use real buttons and links, then check you can do everything with a keyboard.
- Make the focus outline visible. Never remove it without replacing it.
- Put a visible label on every form field.
- Check text contrast, especially small grey text.
- Respect reduced motion settings for anything that animates on its own.
- Write error messages that say what went wrong and how to fix it.
None of this is glamorous. Neither is a handrail. Build it in from the first drawing and nobody will ever have to notice it.
- Frontend
- Accessibility