A Lighthouse Accessibility Score of 100 Is Not WCAG Conformance

A Lighthouse accessibility score of 100 means a template passed the automated checks on the one page you ran it against. It is not a WCAG conformance claim, it does not cover the pages you did not test, and it cannot see the failures that matter most on a marketing site — the control that only appears on hover, the menu that removes itself from a screen reader's link list, the carousel whose off-screen slides are not in the HTML.

We score 100 on accessibility across eight pages, on desktop and on mobile. This post is about what that score did not catch, what we had to find by hand, and the ten-minute test you can run on any template before buying it.

What the score measures, and what it cannot

Lighthouse's accessibility category runs axe-core rules: contrast ratios, missing alternative text, form labels, ARIA attribute validity, heading order, landmark structure. These are the checks a machine can make from the DOM alone, and they are genuinely valuable — every one of them is a real WCAG success criterion.

The limit is structural, not a flaw in the tool. A large share of WCAG's success criteria require judgement: whether alternative text is accurate, whether focus order is logical, whether an error message explains how to fix the problem. No static analysis can decide those.

How large a share is contested, and worth stating with attribution rather than as a fact. Deque, who build axe-core, published a study across 13,000+ page states and roughly 300,000 issues putting automated coverage at 57% — deliberately framed by them as beating the accepted industry benchmark, which tells you what the benchmark was. Independent write-ups of Lighthouse's own coverage commonly land nearer 30–40%. We are in no position to adjudicate between those numbers, and the honest reading is that they are measuring different things on different corpora. But note that both are a fraction, and both describe the ceiling for any score you can read off a dashboard.

The useful framing:

A 100 means nothing automated is broken here. It says nothing about whether the page is usable.

Our numbers, and the part they hide

The full result of our last audit, run against the production build:

Now the part that is easy to miss: an earlier pass covered only three pages. /blog, /docs and the article pages were built afterwards, and nobody had ever measured them. Extending the same audit to every page immediately produced three genuine defects on pages that had shipped:

1. /blog had no <h1> at all. The index title used a section-heading component that defaults to h2. The page's subject was unstated — nothing for a screen-reader user to orient on, and nothing for a crawler. Fixed by promoting it to h1 and shifting card titles h3 → h2 so the outline stays contiguous.
2. /docs skipped h1 → h3. A skipped heading level breaks the document outline that screen-reader users navigate by. The first section heading is now h2; the visual size class did not change at all, only the semantic level.
3. A tag chip failed AA contrast by a hundredth. Brand blue #465fff on #f2f7ff at 12px measures 4.49:1 against a 4.5:1 requirement. Moved one step darker on the brand scale.

A static sweep now confirms all 16 sampled routes have exactly one <h1> and no skipped heading levels, which is the check that would have caught the first two on the day they shipped.

The lesson is not "we found bugs". It is that a score is a claim about a URL, and a template is a set of URLs. A demo whose home page scores 100 tells you about the home page.

The failures no scanner reports

Everything above was machine-detectable — we simply had not run the machine everywhere. These next three were not, and they are the ones that decide whether the template is usable.

A hover overlay is not a control. Our product cards reveal a blurred overlay with a preview action on group-hover. A touch screen has no hover, and an invisible child cannot receive focus, so on a phone and via the keyboard that action did not exist. Automated checks pass this cleanly: the element is correctly marked aria-hidden and out of the tab order, which is exactly right for a decoration. The fix is not ARIA. It is a second, always-visible button, so the hover overlay is a pointer shortcut and never the only route in.

A navigation menu is not an application menu. The ARIA menu/menuitem pattern that most mega-menu tutorials copy is meant for application menus — the File/Edit kind. Applied to site navigation it removes your nav from the screen reader's list of links, which is one of the primary ways people navigate a page. A scanner sees valid ARIA and says nothing. The correct pattern is a navigation landmark with disclosure buttons.

A virtualized carousel hides content from everything. Rendering only the active slide removes the rest from the HTML — invisible to assistive technology and to crawlers alike. Our gallery keeps every slide mounted in a translated track and starves the off-screen ones of loading priority, so advancing a slide is a transform rather than a fetch.

Three failures. Zero automated findings. All three affect real users on real devices.

The legal picture, briefly and as of 2026

Accessibility has become a procurement question rather than a nice-to-have, and two changes are why:

• The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025, covering — among other things — e-commerce and consumer banking services sold to EU consumers. The technical benchmark in practice is EN 301 549, which incorporates WCAG at level AA.
• The ADA Title II rule finalised by the US DOJ in April 2024 sets WCAG 2.1 AA as the standard for state and local government web content, with compliance dates in 2026 and 2027 by entity size.

Neither of those regulates a template you bought. Both of them regulate the site you build with it — which makes the template's baseline your starting debt. WCAG 2.2 AA has been the current W3C Recommendation since October 2023 and is the sensible target; 2.1 AA is the floor most regulation names.

If your site is a regulated one, treat any template's accessibility claim as a starting point to verify, not a compliance artifact to inherit.

A ten-minute test to run before you buy

You can do all of this on a public demo, with no purchase and no tooling beyond a browser.

The two rows people skip are the two that separate templates: inner pages and mobile. A demo home page is the page the seller optimised.

Our own pre-purchase pass covers the wider buying decision — licence, route count, update policy — and treats accessibility as one of ten checks. This post is that check taken to the bottom.

Mistakes and how they show up

Frequently asked questions

Is a template with a Lighthouse 100 worth paying more for? It is worth something — it means the obvious machine-checkable failures are absent, which is a real signal about care. It is not worth much if the score covers one page. Ask which pages were measured; a seller who audited every route will say so specifically.

What is the single highest-value manual check? Keyboard-only navigation of a page with cards, menus and a modal. It exercises focus visibility, focus order, focus return and hover-only controls in one pass, and it is where most template failures actually live.

Does WCAG 2.2 AA versus 2.1 AA matter when choosing a template? Slightly. 2.2 added criteria around focus appearance, dragging alternatives and target size that catch real UI patterns. But no template ships a conformance guarantee for either, so use the version to set your own target rather than as a filter.

Can I make an inaccessible template accessible after buying? Usually yes for contrast, headings and labels — those are localised edits. Much harder if the failure is structural: a navigation pattern, a modal without focus management, or an interaction that only exists on hover. Those are the ones to check before you pay, because they are rewrites rather than tweaks.

Should I trust an accessibility overlay widget instead? No. Overlays sit on top of the markup rather than fixing it, and they are widely rejected by the accessibility community and by disabled users themselves. Fix the template.

Templates audited on every page, not just the demo home page

Regulated sectors are where this stops being optional — consumer finance and insurance sites sold into the EU are squarely inside the Accessibility Act's scope. The templates below are built on the same conventions this post describes: one h1 per route, contiguous heading outlines, contrast measured against the token scale rather than eyeballed, and no control that exists only on hover.