Web & frontend · Mixed

Accessibility: the minimum you can't skip

In one line: Most accessibility comes from writing correct HTML, and most failures come from replacing standard elements with something drawn to look like them.

Four things that cover most of it

Correct elements. A button is a button, a link is a link, headings in descending order. A div with a click handler isn't keyboard-accessible and isn't announced by a screen reader.

Contrast and size. Light grey text on white is the most common problem, and it's solved by changing one colour variable.

Keyboard. Walk the whole flow with Tab only. If you can't close a popup or reach a button, that's a block.

Alt text and labelled forms. A description for every meaningful image, a linked label for every field.

What to check and how

An automated tool catches about a third of the issues and is worth running on every build. The rest you catch in two short manual checks: a keyboard pass, and having a central page read out by a screen reader.

The manual check takes fifteen minutes a page and reveals things no tool will see — for example that the tab order jumps between areas.

Why it pays off commercially too

The same fixes improve use on mobile, in sunlight, and on a slow connection. And in many places, website accessibility is also a regulatory requirement — worth checking your standing with someone qualified.

Going deeper

Build the base components once — button, field, dialog, menu — with correct focus management and roles, and don't allow them to be rewritten on every screen. Accessibility is achieved at the system level, not at the point of the individual fix.