Tools

Lighthouse

Google's open-source web-quality auditor, bundled with Chrome DevTools and the PageSpeed Insights API. Its accessibility audit wraps axe-core's rule set. Scores 0–100, but a score of 100 doesn't mean WCAG-compliant.

Lighthouse is Google’s open-source automated web-quality auditor. Bundled directly into Chrome DevTools, it runs four audits — Performance, Accessibility, Best Practices, and SEO — and produces a 0-to-100 score in each category. The accessibility audit specifically is a subset of axe-core’s rule set, packaged into Lighthouse’s reporting format.

What Lighthouse Accessibility actually measures

The Accessibility category in Lighthouse runs a curated subset of axe-core rules — typically 40-50 rules, chosen because they are deterministic, fast to execute, and produce zero false positives. The rules cover the usual ground:

  • ARIA attribute validity.
  • Colour contrast.
  • Form label presence.
  • Image alt-text presence.
  • Language attribute on <html>.
  • Heading structure (some checks).
  • Link discernibility (link has accessible name).
  • Focus indicator existence.

Each rule contributes to the 0-to-100 score using a weighting Google publishes in the Lighthouse documentation. Critical rules (no accessible name on a control, missing alt on an informative image) weigh heavily; advisory ones weigh less.

The crucial misunderstanding

A Lighthouse Accessibility score of 100 does not mean the site is WCAG-compliant. Lighthouse runs the automated-detectable subset of WCAG checks. That subset is a fraction of the full WCAG ruleset.

Specifically, Lighthouse does not evaluate:

  • The quality of alt text (only its presence).
  • Focus order matching visual order.
  • Whether interactive widgets implement their full keyboard contract.
  • Whether ARIA live regions announce changes correctly.
  • Real screen-reader behaviour.
  • Content readability and cognitive load.

A team that ships a site with Lighthouse Accessibility = 100 has cleared the lowest bar; they have not done the work.

That said, failing to clear that bar is a real problem. A Lighthouse Accessibility score below 100 means automated-detectable failures exist on the page — and those are the cheapest, lowest-friction issues to fix.

How to use Lighthouse operationally

Lighthouse fits naturally into three workflows:

  1. DevTools spot-check. Open DevTools → Lighthouse panel → Run audit. Useful for one-off page checks during development.
  2. CI gate. lighthouse-ci runs Lighthouse on every PR, fails on regressions, and stores history. The disabilityworld.org repo’s CI uses this pattern: every push runs Lighthouse against representative pages and must hit 100 across Performance, Accessibility, Best Practices, and SEO.
  3. Real-User Monitoring. PageSpeed Insights API runs Lighthouse on demand against any public URL, and Chrome User Experience Report (CrUX) reports real-user metrics for the same dimensions.

The full 100-100-100-100 target

For static-published sites with disciplined CSS, font, and image handling, Lighthouse 100s across all four categories are achievable and worth targeting. The combination signals:

  • Performance 100 — fast on slow networks and devices.
  • Accessibility 100 — clears the automated-detectable floor.
  • Best Practices 100 — modern HTTP, no console errors, image aspect ratios stable.
  • SEO 100 — crawlable, meta-described, semantic.

This site (disabilityworld.org) aims for that floor on every published article and verifies it in CI. The Accessibility 100 is the table-stakes result; the manual a11y work that isn’t in Lighthouse is where the real accessibility programme lives.