Accessibility isn't a specialist's job - five checks anyone building a page can run today

Background

Accessibility gets treated as a specialist audit that happens at the end - a report with a traffic-light score, a backlog of tickets, a slow grind back towards compliant. That's the expensive way to do it. Most of what actually matters day to day isn't specialist knowledge at all; it's five checks anyone building a page can run in the time it takes to make a coffee, before the thing ships rather than after someone complains it doesn't work for them.

None of what follows needs a paid audit tool or a certification. It needs ten minutes, a keyboard, and a habit of running the same checks every time, in the same order, until they stop being a checklist and become how you build.

Setup

The five-minute checklist

1. Tab through the page without touching the mouse. Can you reach every link, button and form field, in an order that makes sense? Is there always a visible outline showing where you are? If focus disappears into a menu you can't get back out of, or a button only responds to a click and not to Enter, that's not a screen-reader-only problem - it's broken for anyone using a keyboard, including someone with a repetitive strain injury who simply can't use a mouse today.

2. Check contrast, not just "does it look fine." Body text needs 4.5:1 against its background; large text needs 3:1. Grey-on-white and pale colour combinations that look fashionable on a bright monitor routinely fail this on an older screen or in daylight. Free browser devtools panels measure this directly - no purchase needed, no guessing by eye.

3. Write alt text that describes function, not just content. A decorative image gets an empty alt="" so a screen reader skips it. A photo that's purely illustrative gets a short, honest description. A button that's an icon with no visible label - a magnifying glass, a trash can - needs alt or aria-label text describing what it does ("Search", "Delete this row"), not what it looks like ("Icon of a bin").

4. Check every form field has a real, associated label, not a placeholder standing in for one. A placeholder disappears the moment someone starts typing, and several screen readers don't announce it at all. <label for="email">Email address</label> costs one line and means the field is still identifiable after the person's typed the first character.

5. Check the heading structure makes sense read in order, on its own. One <h1> per page, headings nested logically underneath it, chosen for what they mean in the document's structure rather than for what size looks good. Someone navigating by headings - a common screen-reader shortcut - is reading your <h1> through <h6> tags as a table of contents. If they don't nest sensibly, that shortcut stops working.

A browser's own accessibility panel, plus a free extension like axe or WAVE, catches most of the above in minutes and points at the exact element that failed, so you're never guessing which of forty <div>s is the problem.

Three ARIA mistakes that look like fixes but aren't

ARIA gets reached for as the accessibility fix when semantic HTML would have done the job better and with less risk of getting it wrong:

• role="button" on a <div>, instead of using an actual <button>. The role makes a screen reader announce it as a button. It does nothing about keyboard focus, Enter/Space activation, or any of the built-in behaviour a real <button> gets for free - all of which now has to be hand-built and gets forgotten more often than not.
• aria-label overriding text that's already visible on screen. If a button visibly says "Submit" and carries aria-label="Send this form to the finance team", a sighted keyboard user and a screen reader user are now hearing about two different buttons. The label should match what's on screen, or add to it - never replace it with something nobody sighted ever sees.
• aria-hidden="true" on something that still receives keyboard focus. Hiding an element from a screen reader while it can still be tabbed to produces a focus outline on a phantom element nobody's told exists. If it's genuinely decorative, it shouldn't be focusable either.

The rule of thumb worth keeping: reach for a real HTML element before an ARIA attribute, every time one exists that does the job. ARIA is for filling genuine gaps in HTML's own vocabulary, not for patching over choosing the wrong element in the first place.

A release-day testing routine

Run this before anything goes live, not after someone reports a problem:

• A full keyboard-only pass of the actual page or feature that changed, not just the homepage - tab in, tab through, activate everything, tab out.
• Zoom the browser to 200% and check nothing overlaps, gets clipped, or becomes impossible to reach. This also surfaces most responsive-layout bugs that a narrower device-width test alone would miss.
• Turn on a screen reader for five minutes (NVDA on Windows and VoiceOver on Mac are both free) and listen to the page read itself, particularly anything that changed. You don't need fluency to notice a button announced as "button" with no name, or a form field that gets skipped entirely.
• Check with reduced motion enabled (prefers-reduced-motion in your OS settings) if the page has any animation - a parallax effect or an auto-playing carousel that ignores this setting is a real problem for someone with a vestibular disorder, not a nice-to-have to respect.

Building it into the workflow, not bolting it on after

The five-minute checklist only stays cheap if it happens before a design decision ships, not after. Two habits make that stick:

• Contrast-check colour tokens at the point they're chosen, not per page they end up used on. A colour that fails 4.5:1 caught in a design token file is a five-minute fix. The same colour caught after it's been used across forty screens is a re-theme.
• Add the five checks as an actual line item on a pull request template or a definition of done, not a value everyone's assumed to already know. A checklist that exists only in someone's head gets skipped the first time a deadline's tight; a checklist that's a literal tick box on the PR gets run anyway.