Skip to main content
Back to all posts

How Accessibility Scores Are Calculated (Lighthouse, axe, Custom)

Benjamin Morton

A developer once built a website that scores a perfect 100 for accessibility in Lighthouse and is, on purpose, almost impossible for a disabled person to use (Manuel Matuzovic). It's the single best illustration of what an accessibility score is: a proxy, not a verdict. The number tells you something, but not the thing most people assume it tells you.

So what is the number, exactly? Different tools compute it in completely different ways, and some don't produce a score at all. This post walks through how Lighthouse, axe-core, WAVE, and a custom scanner each turn a page into a result, using our own scoring code as a worked example, so you know what a score is worth before you put it in a dashboard.

Key Takeaways

  • Lighthouse's accessibility score is a weighted average of pass/fail audits, weighted by axe user-impact, with no partial credit (Chrome for Developers, 2025).
  • A perfect score is not proof of accessibility: automated tools catch only about 30-57% of issues, and you can score 100 on a deliberately broken page.
  • axe-core and WAVE don't emit a 0-100 score at all; they report violations by impact or as raw counts.
  • A custom score is a weighting choice. a11yFlow weights each violation critical 10, serious 7, moderate 3, minor 1, and a passing check 3.

How Does Lighthouse Calculate Its Accessibility Score?

It's a weighted average of pass/fail audits. Lighthouse runs a set of accessibility audits (powered by axe-core under the hood), gives each a weight based on axe's user-impact assessment, and averages them. The result is normalised to 0-100 and shown in a coloured ring: red for 0-49, orange for 50-89, green for 90-100 (Chrome for Developers, 2025).

The detail that catches people out is that each audit is strictly pass or fail. There's no partial credit: an audit with one failing element and ninety-nine passing ones fails completely and contributes nothing (Chrome for Developers, 2025). Effectively, your score is the passed audits' weight over the total applicable weight:

score ≈ (weight of passed audits) ÷ (weight of all applicable audits) × 100

Weights run up to 10, and the heaviest audits are the ones that block assistive tech hardest: valid ARIA roles and attributes, accessible names for buttons and links, alt on images, and labels on form fields all carry the maximum weight of 10 (Chrome for Developers, 2025). Fail one weight-10 audit and your score drops far more than failing a minor one.

Does a Lighthouse 100 Mean Your Site Is Accessible?

No. The score only measures what a machine can check, and that's a minority of accessibility. Google says so directly: "not all checks can be automated," and automated tools "don't catch all of the accessibility errors in your product" (web.dev, 2023). A green ring means you passed the automated subset, nothing more.

How Much of WCAG Can Automation Catch? By success criteria ~30-40% By issue volume (Deque) 57% 0% 50% 100% Two ways of counting the same audits. Neither is most of real accessibility. Sources: Deque Automated Coverage Report (issue volume); success-criteria convention.

How big is that subset? It depends how you count, and the honest answer is a range. Deque's analysis of 13,000-plus pages found automated axe caught 57% of issues by volume, but that counts individual issues; measured against WCAG success criteria, the conventional figure is lower, around 30-40% (Deque, 2022). Either way, roughly half of accessibility, and often the half that matters most (does the keyboard flow make sense, does the screen reader announcement read right), sits outside what any score can see.

Citation capsule: A Lighthouse accessibility score is a weighted average of pass/fail audits, weighted by axe's user-impact ratings, with no partial credit (Chrome for Developers, 2025). A perfect 100 certifies only the automated subset of WCAG, which Deque puts at about 57% of issues by volume (Deque, 2022). Google itself states that "not all checks can be automated," so a green score is a floor, not a pass.

What Score Does axe-core Give?

This surprises people who assume the engine behind Lighthouse hands out grades. It doesn't. Run axe-core directly and you get four arrays back, not a number: passes, violations, incomplete, and inapplicable (axe-core API, 2026). Any 0-100 score you've seen from an axe-based tool was computed by that tool, on top of axe, not by axe itself.

What axe does give each violation is an impact level, and that's the raw material every custom score is built from. Deque assigns the impact per rule, based on how badly the failure blocks assistive-technology users:

Impact

What it means

Critical

Blocks content entirely; will definitely stop users reaching core features or content

Serious

A serious barrier; will partially or fully block access to core features

Moderate

Causes some difficulty, but generally won't block access

Minor

A nuisance or annoyance

The impact isn't calculated at runtime; it's baked into each rule's metadata (axe-core, 2026). A missing form label is always "critical"; a redundant title attribute is always "minor." That fixed severity is exactly what lets a scanner turn a pile of violations into a single weighted number.

And WAVE?

WAVE takes the opposite approach: it shows you counts and refuses to grade. Point WebAIM's WAVE at a page and you get categorised tallies (errors, contrast errors, alerts, features, structural elements, ARIA), not a 0-100 score (WAVE, 2026). By design, WAVE "facilitates human evaluation" rather than replacing it: the counts are a starting point for a person, not a verdict.

That's a deliberate philosophy, not a missing feature. A single number invites you to chase the number; a pile of categorised issues invites you to look at each one. (Note: Deque and WebAIM do sell products with human-derived "scores," but the free WAVE tool isn't one of them. Don't confuse the two.) For how these tools line up against each other, our axe vs Lighthouse vs WAVE vs Pa11y comparison breaks down what each is good for.

How Does a Custom Scanner Turn Violations Into a Score?

Here's where the opinion lives. A custom score is just a decision about how much each kind of failure should hurt, applied consistently. To make that concrete, here's the actual scoring function a11yFlow uses:

const IMPACT_WEIGHTS = { critical: 10, serious: 7, moderate: 3, minor: 1 };
const PASS_WEIGHT = 3;

function computeScore(passCount, violations) {
  const passingWeight = passCount * PASS_WEIGHT;
  const failingWeight = violations.reduce(
    (sum, v) => sum + (IMPACT_WEIGHTS[v.impact] ?? 3),
    0,
  );
  const total = passingWeight + failingWeight;
  return total > 0 ? Math.round((passingWeight / total) * 100) : 100;
}

Every passing check earns 3 points. Every violation subtracts weight according to its axe impact, and the score is the passing weight as a share of all the weight on the page. It borrows Lighthouse's shape (impact-weighted, normalised to 100) and axe's severity levels (critical down to minor) as the weights.

How a11yFlow Weights a Violation by Impact Critical 10 Serious 7 Moderate 3 Minor 1 A passing check is worth 3. A single critical failure outweighs three passes. Source: a11yFlow computeScore, packages/shared

Work an example. Say a page has 40 passing checks, one critical violation, and two serious ones. Passing weight is 40 × 3 = 120. Failing weight is 10 + 7 + 7 = 24. The score is 120 ÷ 144 × 100, which rounds to 83. Fix the critical one and the score climbs to 87; the weights decide how much each fix is worth.

The lesson from building this: the hard part of scoring isn't detection, it's deciding what to punish. Should ten minor issues sink a page more than one critical? Should a violation count once, or once per element it affects? There's no correct answer, only a defensible one, and every scanner's number encodes its author's opinion about which failures matter most. That's the real reason to distrust cross-tool comparisons.

Why Does the Same Page Score Differently Everywhere?

Because the tools aren't measuring the same thing. Lighthouse runs a weighted set of binary audits; axe hands back impact-tagged violations with no total; WAVE counts categories; our scanner weights by severity and prevalence. Feed one page to all four and you get a 100, a list, a set of tallies, and an 83, none of which are wrong, because they answer different questions.

The practical consequence: a score is only comparable to itself. Tracking your Lighthouse accessibility score over time is useful; it tells you whether you're regressing. Comparing your Lighthouse score to a competitor's axe-derived score is meaningless. And none of them should be read as a conformance claim. WebAIM makes the point at the scale of the whole web: only 4.1% of the top million home pages have zero detected errors, but WebAIM warns that "absence of detected errors does not indicate that a page is accessible," and true WCAG conformance is "certainly lower than 4.1%" (WebAIM Million, 2026). The full statistics make the same case: a clean automated result is a floor to build on, not a finish line.

Frequently Asked Questions

How is the Lighthouse accessibility score calculated?

It's a weighted average of accessibility audits, each scored pass or fail, with weights based on axe's user-impact ratings and no partial credit (Chrome for Developers, 2025). Effectively, it's the weight of passed audits over the total applicable weight, shown as 0-100. The heaviest audits (ARIA validity, labels, alt text) carry a weight of 10.

Does a 100 accessibility score mean my site is accessible?

No. A perfect score means you passed the automated checks, which cover only about 30-57% of issues (Deque, 2022). Google states plainly that "not all checks can be automated" (web.dev, 2023). Someone has literally built a deliberately inaccessible page that scores 100, so treat the number as a floor, not proof.

What score does axe-core give?

None. axe-core returns arrays of passes, violations, incomplete results, and inapplicable rules, with no aggregate 0-100 score (axe-core, 2026). Each violation carries an impact level (critical, serious, moderate, or minor). Any score from an axe-based tool was added by that tool on top of axe.

What is a good accessibility score?

There's no universal threshold, because scores aren't comparable across tools. A high score in one tool only means you've cleared its automated subset. Use a score to track your own trend over time, not to declare conformance or to compare against a site scored by a different tool with different weights and rules.

Why do Lighthouse and axe give different results for the same page?

Because they measure different things. Lighthouse averages weighted pass/fail audits into a single number; axe returns impact-tagged violations with no total. They run overlapping but not identical rule sets and aggregate them differently, so the same page produces a score in one and a raw list in the other. Compare a tool only to itself.

The Bottom Line

An accessibility score is a compression of a complex reality into one number, and every tool compresses differently. Lighthouse averages binary, impact-weighted audits; axe refuses to total anything and just tags severity; WAVE counts and hands the judgement to you; a custom scanner like ours picks weights (critical 10, serious 7, moderate 3, minor 1) and normalises to 100. Knowing which one you're looking at tells you what it can and can't promise.

None of them can promise accessibility, because automation catches roughly half of it at best, and you can hit 100 on a page no one can use. Use scores the way they're actually useful: as a regression signal for your own site over time, and a prompt to go do the manual and assistive-technology testing that the number can't. If you want a scanner that's honest about that boundary, that's exactly what a11yFlow's API is built to be, and where the fixes for the failures it finds start.

Sources

PreviousFocus Management in SPAs: Accessibility Patterns
NextAccessibility Testing for Startups: API-First on a Budget