Methodology

What AccessLumens measures

AccessLumens runs an automated evaluation of a website, or of a PDF document, 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.

Before any of our proprietary checks is allowed to affect a score, we develop and regression-test it against real-world reference sites using a live browser-automation harness (Playwright, driven through the Model Context Protocol). Each heuristic must stay silent on standards-leading, known-good sites — such as GOV.UK — before it ships, and is re-validated against deliberately broken pages to confirm it still catches genuine failures. This keeps false positives low without dulling the checks. The harness is a development and validation tool only; it is not part of the live scan.

PDF document analysis

Uploaded PDFs are checked by the AccessLumens PDF engine against WCAG 2.2 Level AA and the PDF/UA document accessibility standard (ISO 14289-1, and PDF/UA-2 when selected). The engine inspects the document’s structure directly rather than its appearance: the tag tree and reading order, alternative text on figures, heading nesting, table headers and scope, list structure, the document language and title, form field labels, and link annotations.

Colour contrast is measured by rendering each page and sampling the actual pixels behind every run of text, rather than inferring a background from the drawing instructions. That matters because a PDF’s painted background is often an image, a gradient, or a shape stack that a purely structural read would get wrong. Each failing run is reported with its measured ratio, the required ratio for its size, and a cropped screenshot of the page showing the affected text outlined in place. Contrast analysis covers the first 60 pages of a document; when a document is longer, the report states how many pages were analysed.

Findings are then mapped to their WCAG success criteria, assigned a severity, deduplicated across pages, and scored on the same 0–100 model described below. Standards conformance results are produced with the help of established open-source validation components, credited in the closing note of every PDF report. As with website scans, the result is a diagnostic tool and not a formal conformance certification: criteria such as whether a document’s reading order is logical still require human review.

Uploaded documents are processed in memory and deleted as soon as the check finishes. Only the findings are retained, so you can return to your report.

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.
• Non-text contrast — checks that form fields present a visible boundary (a border, distinct fill, or shadow) with at least 3:1 contrast against their surroundings, so low-vision users can tell where a control is, per WCAG 1.4.11. The whole page is probed — each field is scrolled into view — and only a systemic majority of unbounded fields is reported.
• 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.
• Password-protected, corrupt, or scanned-image PDFs cannot be structurally analysed; a PDF that is purely a picture of text has no structure to check and is reported as such.
• 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.