My practical accessibility smoke test before release

Accessibility testing gets framed as a specialist discipline you need certification and a screen reader fluency to attempt. That framing is how it ends up tested by nobody. The truth is that most accessibility bugs that reach production are obvious ones — the kind you find in ten minutes with no tooling, if you know where to look. A specialist audit is still worth doing periodically. But the smoke test below is what stops the embarrassing failures from shipping every sprint.

Here's the pass, roughly in the order I run it.

1. Unplug the mouse

The single highest-value check: put the mouse down and drive the whole flow with Tab, Shift+Tab, Enter, Space, and the arrow keys. Can you reach every control? Can you activate every control? The places you get stuck are exactly the places a keyboard-only or screen-reader user gets stuck. Custom dropdowns, modals, and "clickable divs" are the usual offenders — a <div onClick> isn't reachable by keyboard at all.

2. Watch the focus indicator

While you're tabbing, watch for the focus ring. Can you always see where you are? A design that removes outline: none without replacing it leaves keyboard users navigating blind. If you lose the focus indicator anywhere, that's a bug — note the control and move on.

3. Check focus order and traps

Does focus move in the order the page reads — left to right, top to bottom — or does it jump around because the DOM order doesn't match the visual order? Then the trap test: open a modal. Does Tab stay inside it, and does Esc close it? A modal that lets focus escape to the page behind it, or won't close from the keyboard, is one of the most common — and most reported — accessibility defects.

4. Tab to the top: is there a skip link?

Load the page and press Tab once. A "Skip to main content" link should be the first stop, letting users jump past the nav. Its absence isn't catastrophic, but it's a quick, telling signal of how much keyboard use the team considered.

5. Forms: labels, errors, and focus

For every input, click the visible label — does it focus the field? If not, the label isn't associated and a screen reader won't announce it. Then submit the form with errors: are the errors announced and is focus moved to them, or do they appear silently in red that a screen-reader and a colourblind user both miss? Error handling is where forms most often fail accessibility.

6. Images and icons

Are meaningful images described, and are decorative ones silent? An icon-only button (a bare ✕ or 🔍) with no accessible name is invisible to a screen reader — it announces "button" and nothing else. Quick check: would this control make sense if you couldn't see the icon?

7. Zoom to 200%

Zoom the browser to 200%. Does the content reflow and stay usable, or does text get cut off, overlap, or force horizontal scrolling? Plenty of users run zoomed in permanently, and fixed-pixel layouts break for them in ways that never show at 100%.

8. Run axe — but know its ceiling

Now run an automated scan (axe is the engine behind most of them). It'll catch contrast failures, missing alt text, and unlabelled fields fast. But automated tools catch only a fraction of issues — they can't tell you whether the focus order makes sense, whether the error message is useful, or whether a custom widget actually works with a keyboard. Axe is the smoke alarm; steps 1–7 are you actually checking the kitchen.

Where this fits

This is a release gate, not a substitute for a proper audit or for involving real assistive-technology users. If you want the longer version, the accessibility checklist goes deeper, and the glossary covers the terms — WCAG, ARIA, focus order, accessible name — that make the audit reports readable.

The 10-minute accessibility smoke test

• Every control is reachable AND activatable by keyboard alone
• The focus indicator is always visible
• Focus order matches reading order; modals trap focus and close on Esc
• A "skip to content" link is the first tab stop
• Clicking a label focuses its field; form errors are announced and focused
• Icon-only buttons have an accessible name; decorative images are silent
• Content reflows and stays usable at 200% zoom
• An axe scan is clean — and you've checked the things axe can't see