Automated accessibility tools catch a useful slice of WCAG issues, and it's the boring slice, so run them. But it's only a slice: a page can pass every automated check and still be unusable with a keyboard or a screen reader.
This checklist splits the work into what a tool can tell you and what only you can. Start with the automated pass because it's cheap, then spend your real time on the manual one.
The automated pass
Run one of the axe-based tools (Lighthouse's accessibility audit, the axe DevTools extension, or WAVE) and fix everything it reports. These are the categories it covers well:
- Images without
altattributes - Form inputs without an associated label
- Buttons and links with no accessible name
- Colour contrast below the WCAG threshold
- Missing
langon<html> - Duplicate IDs and invalid ARIA attribute names
- Missing document title
- Skipped heading levels
Web Developer Tools covers the same ground with 25 accessibility utilities that annotate the page rather than producing a list you then have to map back to elements. Highlight Missing Labels outlines inputs with no label or aria-label, Highlight Empty Buttons and Highlight Empty Links outline controls with no text content, Detect Invalid ARIA finds misspelled attributes, and Detect Low Contrast marks text failing the contrast guidelines. Seeing the failures in place, on the page, makes the fix obvious in a way a report row rarely does.
The keyboard pass (do this one first)
If you only have fifteen minutes, spend it here. Put the mouse down, press Tab, and work through the page.
- 1
Can you see where you are?
Every focused element needs a visible focus indicator. If someone removed the default outline with
outline: noneand didn't replace it, focus becomes invisible and the page is unusable without a mouse. Turning on Highlight Keyboard Focus in WDT forces a high-visibility ring onto everything focusable, which makes the audit quick. - 2
Does the order make sense?
Focus should follow the visual reading order. It breaks when CSS reorders things (flex
order, grid placement, absolute positioning) or when someone has scattered positivetabindexvalues. View Tab Order draws numbered badges over the page so you can read the sequence at a glance. - 3
Can you reach everything interactive?
Anything clickable must be reachable. A
<div onclick>isn't focusable and won't receive keyboard events, which is the single most common custom-widget failure. - 4
Can you get out again?
Open every modal, dropdown and date picker, then try to leave with
EscandTab. A focus trap that never releases is a hard stop for a keyboard user. WDT has a Focus Trap Detector for the ones that aren't obvious. - 5
Does
EnterandSpacedo what it should?Links activate on
Enter. Buttons activate on bothEnterandSpace. Custom controls need this wired up manually, and half the time onlyEnteris handled. - 6
Is there a skip link?
The first
Tabon a page should offer a way past the navigation. It's allowed to be visually hidden until focused. WDT's Check Skip Links finds missing or broken ones.
Structure and semantics
Screen reader users navigate by structure: headings, landmarks, lists, links. If the structure is wrong, the page is technically readable and practically unnavigable.
Headings
One <h1> per page, no skipped levels, no headings used purely for their font size. Screen reader users navigate by heading constantly, so this is not a cosmetic concern. Outline Headings labels every heading in place with its level, and Heading Accessibility Audit flags skipped levels and empty headings.
Landmarks
<header>, <nav>, <main>, <aside>, <footer>. One <main>, and if you have two <nav> elements, give each an aria-label so they can be told apart. View Landmarks outlines and labels them, which quickly reveals pages where everything is a <div>.
Native elements first
<!-- Needs role, tabindex, keydown handling, focus styles, aria-pressed... -->
<div class="btn" onclick="save()">Save</div>
<!-- Gets all of it for free -->
<button type="button" onclick="save()">Save</button>The first rule of ARIA is not to use ARIA. A <button>, <select> or <details> gives you keyboard behaviour, focus management and correct announcement without a line of JavaScript. Reach for ARIA when there is genuinely no native equivalent.
Names, roles and values
Every interactive element needs an accessible name. Not a visible label necessarily, but a name.
| Pattern | Problem | Fix |
|---|---|---|
| Icon-only button | Announced as "button" | aria-label="Close dialog" |
| Input with placeholder only | Name disappears once typing starts | A real <label for> |
<a> wrapping an image | Named by the image | Meaningful alt, or aria-label on the link |
| "Read more" links | Identical names in a list of links | Add context, or aria-label with the article title |
| Form errors in plain text | Never announced | aria-describedby plus a live region |
Hovering with Accessible Name Viewer on shows the computed name, which settles most arguments about what a screen reader will actually say. The aria-labelledby Inspector and aria-describedby Inspector draw lines between the references, and that's the fastest way to find an aria-labelledby pointing at an ID that no longer exists.
Colour and contrast
The thresholds: 4.5:1 for normal text, 3:1 for large text (18pt, or 14pt bold), 3:1 for interactive component boundaries and meaningful graphics. AAA raises the first two to 7:1 and 4.5:1.
Places contrast usually fails:
- Placeholder text, which designers love to set at 40% grey
- Disabled states — exempt from the requirement, but still worth being readable
- Text over images or gradients, where it depends on the pixel
- Focus indicators against a coloured background
- Brand colours used for body text rather than for accents
And colour must never be the only signal. Red-bordered invalid fields with no icon or message are invisible to a colour-blind user. Simulate Protanopia, Simulate Deuteranopia and Simulate Tritanopia re-render the page as those forms of colour vision deficiency see it, which is a far more convincing test than reasoning about hex values.
Images and media
- Informative images need
altthat conveys the information, not a filename - Decorative images need
alt=""(empty, not missing) so they're skipped - Complex images like charts need a longer description nearby
- Alt text shouldn't start with "image of" — that part is already announced
- Video needs captions; audio needs a transcript
- Nothing should autoplay with sound
Reading alt text in the HTML is slow. Printing it onto the page with Display Alt Attributes is not, and it makes the ones that say IMG_4821.jpg jump out. Image Accessibility Audit covers the other direction: redundant alt text, and decorative images given descriptions they don't need.
Forms
Forms are where accessibility failures cost real money, because they're where conversions happen.
- 1Every input has a
<label for>matching itsid, or wraps the input - 2Related radio buttons and checkboxes are grouped in a
<fieldset>with a<legend> - 3Required fields are marked with
required, not only with a red asterisk - 4Error messages are associated with their field via
aria-describedby - 5Errors are announced when they appear, using
role="alert"oraria-live - 6Errors say what's wrong and how to fix it, not just "invalid"
- 7Focus moves to the first error on a failed submit
- 8
autocompleteattributes are set on name, email, address and payment fields
Outline Fields Without Labels and Form Accessibility Audit cover the structural half of that list. The error-handling half needs a manual submit-and-listen test; no tool can judge whether your message is useful.
Actually using a screen reader
You don't need to become an expert. Thirty minutes with one will change how you build things.
- macOS — VoiceOver,
Cmd+F5. Navigate withCtrl+Option+arrow keys. - Windows — NVDA, free and the most widely used. Or Narrator, which is built in.
- iOS — VoiceOver in Accessibility settings, worth trying because gestures change how you think about touch targets.
Try one task: reach a specific product and add it to the basket, with the screen off. The gap between "technically compliant" and "actually usable" becomes very clear very quickly.
Motion, zoom and timing
- Honour
prefers-reduced-motionfor anything that animates, parallaxes or auto-scrolls - The page must be usable at 200% browser zoom with no loss of content
- Text must be resizable to 200% without breaking layout
- Time limits need a way to extend or turn off
- Nothing should flash more than three times per second
A pass you can repeat every sprint
Full audits are quarterly work. This shorter loop catches most regressions:
- 1Run the automated scan on the pages that changed
- 2Tab through any new or modified component
- 3Check contrast on any new colour
- 4Confirm new images have meaningful alt text
- 5Confirm new form fields have labels and error associations
- 6Check the page still works at 200% zoom
Six checks, ten minutes, and it stops the slow accumulation that makes annual audits so painful.
Accessibility and semantics are the same problem viewed from different angles, so the guide to inspecting and debugging HTML is a useful companion. Good structure also feeds technical SEO, and both belong in the pre-launch checklist.