Methodology

What AccessLumens measures

AccessLumens runs an automated evaluation of a website against a subset of the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. Automated tools can reliably evaluate only the portion of WCAG that has a deterministic, machine-checkable definition — in practice roughly ~35% of WCAG 2.2 AA success criteria. The remainder (e.g. whether alt text is meaningful, whether content order makes sense, whether an error message is genuinely helpful) requires human judgement.

An AccessLumens report is therefore a diagnostic and prioritisation tool, not a conformance certification. It is excellent at surfacing concrete, fixable defects quickly; it is not a substitute for a manual audit, assistive-technology testing, or legal compliance advice. See our Accessibility Disclaimer for the full caveats.

The detection engine

Page analysis is performed by axe-core, the open-source accessibility rules engine maintained by Deque Systems and one of the most widely used and respected engines in the industry. Each page is loaded in a real, sandboxed headless Chromium browser, fully rendered, and evaluated against the axe-core ruleset. Detected violations are mapped to their WCAG success criteria, assigned a severity, and grouped by the component they affect.

Some findings are produced by AccessLumens’s own checks that extend beyond the core engine — notably the Keyboard & Experience Analysis described below. Supplementary third-party checks may occasionally be surfaced as informational findings; these do not affect the numeric score.

Scan scope

• Single page — evaluates only the exact URL you submit. Fast, and ideal for spot-checking a specific template (a product page, a checkout step, a landing page).
• Site crawl — discovers same-domain links from the entry URL and evaluates up to 10 pages. Crawling follows in-domain links only and skips sign-out links to avoid ending the session.
• User journey analysis — opens a real browser on your machine that you drive. As you navigate, we analyze each page and dynamic state — including content that only appears after interaction (menus, dialogs, expanded panels) — in the exact order a real user moves through the flow.

Before each page is evaluated we scroll the full height to trigger lazy-loaded content, wait for the network to settle, and dismiss common overlay popups (cookie banners, newsletter modals) so they don’t obscure the page. We only ever close overlays — we never click “accept” or take any consent action on your behalf.

Keyboard & Experience Analysis (optional)

When enabled, AccessLumens performs additional interactive checks on the first few pages scanned. These simulate how a keyboard-only user experiences the page:

• Keyboard traps — walks the focus order with Tab and Shift+Tab to detect places where focus cannot move on (e.g. a widget that captures focus and won’t release it).
• Focus visibility — checks whether focused controls show a visible focus indicator.
• Keyboard reachability — flags interactive elements that cannot receive keyboard focus.
• Skip links — checks for a mechanism to bypass repeated navigation.
• Reflow / zoom — checks for loss of content or horizontal scrolling at 320 CSS px (equivalent to 400% zoom), per WCAG 1.4.10.

Because interactive checks can produce false positives on custom widgets, auto-focusing modals, and animations, several of these are reported as “Manual Review” — flagged for a human to confirm rather than asserted as certain defects.

How the score is calculated

The headline number is the Severity-Weighted Benchmark Score (SWBS), version 1.2. It is fully deterministic and rule-based — the same set of issues always produces the same score. It is not generated by AI. The calculation has four stages.

1. Severity weighting

Every issue is assigned a severity, and each severity carries a base penalty weight:

2. Scope (how widespread an issue is)

An issue on every page matters more than the same issue on one page. Each issue’s weight is multiplied by a scope multiplier based on its density — the fraction of scanned pages it appears on. The multiplier rises continuously (no sudden cliffs) between these anchors:

Because density is a proportion, an issue affecting 50% of pages scores the same whether the site has 10 pages or 5,000 — site size doesn’t distort the result. High-severity issues also carry a minimum penalty floor so a single Critical defect can never be rounded away to zero.

3. From penalty to score

The weighted penalties are summed and mapped onto a 0–100 scale with a smooth exponential curve, so that early issues cost more than the hundredth issue on an already-struggling site. The score is then capped by the worst severity present, because a site with an unresolved Critical issue should never display a near-perfect number:

• Any Critical issue present → score capped at 89.
• Any Serious issue present (and no Critical) → score capped at 94.
• Otherwise → up to 100.

Findings flagged for Manual Review are treated at full weight for the purpose of the severity cap and risk level — an unverified possible Critical still constrains the score — but they are always labelled distinctly in the report so you know which findings warrant human confirmation.

4. Risk level

The score maps to a risk level, with floors that reflect the real-world weight of Critical defects:

Potential score

Alongside the current score we show a potential score: the score you would expect to reach after resolving all Critical and Serious issues, holding everything else constant. It represents a realistic near-term ceiling, not a guarantee.

Industry benchmarking

We infer a likely industry from the domain and page content (for example, .gov and .edu domains, or recurring sector keywords) and compare your score against the distribution of other scans in that industry. Benchmarks are directional context, not a precise market ranking, and improve as more sites are scanned.

Versioning

The scoring model is versioned (e.g. SWBS-1.2) and the version is recorded on every report. When we refine the model, existing reports are recalculated under the current version so that scores remain comparable across your account. We publish material changes to the model here.

Known limitations

• Automated testing covers only part of WCAG; manual evaluation remains essential.
• Content that appears only on hover, after authentication, or behind multi-step interactions may not be captured.
• Highly dynamic single-page applications and bot-protected sites may scan incompletely or be blocked entirely.
• Any automated check can produce false positives and false negatives; treat results as findings to verify, not verdicts.

Questions about how a specific result was produced? Email support@accesslumens.com.