Run Lighthouse on a competently built marketing site and you will usually get a green accessibility score. That number is reassuring and it is close to meaningless. Automated checkers test the rules a machine can decide on its own — a missing alt attribute, a button with no accessible name, a contrast ratio it can compute from two hex values. The majority of the WCAG success criteria are not machine-decidable at all, because they depend on whether something makes sense, not on whether it exists.
An image with alt="image1.png" passes every automated test ever written. A tab order that jumps from the logo to the footer and back up to the menu passes too. So does a form where the only thing identifying a field is grey placeholder text that vanishes the moment you type.
What follows is the manual pass we run before we call a site done. It takes about two hours on a small site, needs no software you do not already have, and finds the things the score does not.
First, Run the Automated Tool Anyway
Start with the machine, because it clears the floor cheaply. Chrome DevTools ships Lighthouse; the axe DevTools extension is more thorough and reports which WCAG criterion each issue maps to. Ten minutes, and you have the low-hanging fruit gone before you spend attention on the parts that need judgment.
The trap is treating the resulting score as a grade. Read it as a smoke test: a bad score means something is definitely broken, a perfect score means nothing has been ruled out. Everything below is what remains after the tool goes quiet.
Test One: Put the Mouse Away (10 minutes)
Load the homepage, put your hand in your lap, and press Tab until you have been through the entire page. This single test surfaces more real defects than any other, because keyboard operability is the substrate everything else sits on — screen reader users, switch device users, and anyone with a tremor all depend on it.
Four things to watch for:
- Can you always see where you are? If a designer removed the focus ring with
outline: noneand never replaced it, the focus is still moving — you just cannot follow it. This is the single most common serious failure we find. - Does the order follow the visual layout? Focus should move left to right, top to bottom. Absolute positioning and flexbox
orderare the usual culprits when it does not. - Can you get out of everything you can get into? Open a modal, a cookie banner, a custom dropdown. If
Tabescapes to the page behind it, orEscdoes nothing, that component is a trap. - Does anything clickable get skipped entirely? A
<div onclick>is invisible to the keyboard. If your card, tab, or accordion header is not a<button>or an<a>, it does not exist for a keyboard user.
While you are there, check for a skip link. On a page with a twelve-item nav, a keyboard user presses Tab twelve times before reaching the content — on every page, every time.
Test Two: Read the Headings Alone (15 minutes)
Screen reader users navigate by heading far more often than they read a page top to bottom. Your heading structure is the table of contents, whether you designed it as one or not.
Pull the outline out of the page and look at it in isolation:
document.querySelectorAll('h1,h2,h3,h4,h5,h6')
.forEach(h => console.log(h.tagName, h.textContent.trim()));
You are checking three things: exactly one h1, no skipped levels on the way down, and headings that describe their section rather than decorate it. The failure mode is almost always the same — someone picked h4 because it was the right size, and the document outline is now fiction.
Test Three: Take the Forms Apart (20 minutes)
Forms are where accessibility failures cost money directly, because a form a user cannot complete is a lead you never receive.
Click each field's visible label. If the cursor does not land in the input, the label is not associated with it, and a screen reader will announce an unlabelled field. The fix is boring and takes a minute:
<label for="email">Work email</label>
<input id="email" name="email" type="email"
autocomplete="email" required />
Then check the rest of the chain. A placeholder is not a label — it disappears on input and its contrast is usually poor by design. Error messages must be reachable from the field via aria-describedby, not just painted in red nearby, because colour alone is not information. And autocomplete attributes are a genuine accessibility feature under WCAG 1.3.5, not a convenience: they let a browser fill a name, address, or phone number that a user with a motor or cognitive impairment would otherwise type by hand.
Test Four: Compute Contrast, Do Not Eyeball It (15 minutes)
WCAG 2.1 AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text and for the visual boundaries of interactive controls. Designers routinely miss this, and so did we.
This site's muted grey, #888 on our #0a0a0a background, comes to roughly 5.6:1 — comfortably passing. The footer copyright line is #555 on the same background, which is about 2.7:1, and fails. Same page, same palette, same designer, one value apart. That is the argument for computing the number instead of trusting your eye on a good monitor in a dark room.
Two places people forget to check: the focus indicator itself, which is a non-text control boundary and needs 3:1 against what is behind it, and the second theme. If you ship a light mode and a dark mode, you have two palettes to verify and most teams only ever check the one they use.
Test Five: Zoom to 200% (10 minutes)
Press Cmd/Ctrl and + until the browser reports 200%, then read the page. WCAG requires content to remain usable at that zoom, and separately requires a 320px-wide reflow without a horizontal scrollbar — the same constraint your mobile layout already satisfies, which is why responsive sites usually pass this and fixed-width ones fail it badly.
Look for text clipped by a fixed-height container, a sticky header that now eats half the viewport, and anything that only scrolls sideways.
Why 2026 Is the Year the Argument Got Easier
Accessibility used to be sold on goodwill. It now has a compliance edge on both sides of the Atlantic, which changes who in the client's organisation cares.
In the EU, the European Accessibility Act has applied since June 2025 to a defined set of consumer-facing products and services — e-commerce, consumer banking, e-books, transport ticketing and others — and member states have transposed it into national law, Croatia included. The harmonised technical standard, EN 301 549, points at WCAG 2.1 level AA, which is exactly what the tests above are checking. Microenterprises providing services (broadly, under ten staff and under €2 million turnover) are exempted from the service obligations, so plenty of small firms are outside the scope — but their larger clients are not, and requirements travel down a supply chain fast.
In the US, the pressure comes from litigation rather than a single statute: several thousand ADA Title III web accessibility cases are filed each year, aimed overwhelmingly at retail and consumer sites. Neither of these is legal advice, and scope questions are genuinely fiddly — if a client's exposure is real, that is a conversation for their counsel, not their developers.
What We Actually Do With the Results
Two hours of testing produces a list, and lists get ignored unless they are ordered. We sort by who gets blocked rather than by which criterion number was violated:
- Blocking: a user cannot complete the task at all — keyboard traps, unreachable controls, unlabelled form fields on a contact form.
- Serious: the task is possible but painful — invisible focus, a broken heading outline, failing body-text contrast.
- Polish: everything that improves the experience without gating it.
Most of what lands in the first two buckets is a small, local fix: a div becomes a button, a for attribute appears, a focus style comes back. The expensive part is never the fixing. It is discovering, eighteen months into a design system, that a component everyone reuses was never operable by keyboard, and that the fix now touches forty pages.
Which is the real reason to run this pass early and repeat it. Not the score, and not the lawsuit — just that a site nobody can use is a site nobody uses.