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 plus our own custom rules. axe-core is 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 and our own. 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 - veraPDF plus our own custom rules - 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: whether content is in the tag tree at all, alternative text on figures, heading nesting, table headers and scope, list structure, the document language and title, form field labels, and link annotations.

That distinction has a consequence worth stating plainly, because it is the most common way an automated document check can be right and still miss something. Structural rules compare a document’s tags with each other, never with what is painted on the page. A table whose columns have been flattened into a single column - by a badly configured export, or by an auto-tagging tool - is internally consistent: its rows all have the same number of cells, its cells are nested correctly, and it passes every table rule in the PDF/UA profile. No structural validator can see that it no longer matches the table a sighted reader is looking at. Tables are therefore always worth checking by eye, whatever the score says.

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.

PDF repair

A checked document can also be repaired. The repair runs the same document through a fixed sequence: embedding fonts that were never embedded, building the tag structure a screen reader follows, normalising the file, writing the document language and title, correcting heading levels, marking decorative page furniture as artifacts, and recolouring text that fails contrast. Two of those stages change meaning rather than plumbing, so they are opt-in and only run on the paid path; the rest are structural.

An existing structure is kept, not replaced. The tagger rebuilds a structure from the page content rather than adding to one, so on a document that is already tagged it decides whether to run at all. A structure the check finds sound is never rebuilt, whatever the score - a low score caused by something else, such as faint text, is not a reason to replace it. Font embedding is held to the same rule: the embedder regenerates the file and drops its tags, so it only runs where the structure is about to be rebuilt anyway, and otherwise unembedded fonts are left listed in the report rather than fixed at the cost of the tags.

The title comes from the document. A document with no real title is given the largest text on its first page, where that stands out from the body and reads like a title; watermarks, stamps, page labels and single words are refused. The file name is the fallback, used only when the page offers nothing usable. An existing title is left alone.

Nothing is charged against a prediction. The repair runs for free, the result is re-checked through the identical pipeline the original went through, and the before-and-after you are shown is that measurement. A document that does not improve costs nothing. This matters more than it sounds: in our own testing an auto-tagging bug once took a real document down 49 points while every stage reported success, and a projection-based charge would have billed for that.

Every repaired file passes an output-integrity gate before it is offered at all. The repaired pages are rendered and compared pixel-by-pixel with the original, the text is extracted from both and compared, and form fields are checked for survival. Any of those failing discards our version and keeps yours. The same applies stage by stage: a stage whose result does not hold up is dropped and the document continues without it.

The structure is shown, not just scored. Before payment, the repaired pages are drawn with every tagged element boxed - headings, paragraphs, pictures, tables, lists, links and form fields - and numbered in the order a screen reader will reach them, beside the same view of the original, where content with no tag at all is marked. Pictures without a real description are outlined. Placeholder text such as “image 1” or “description pending” satisfies the automated check while telling a listener nothing, so it is removed from anything we tag and treated as missing in the preview. The same facts are given as text beside the drawing.

Contrast repair changes the fill colour of failing text and nothing else. Each colour moves only as far as passing requires and keeps its hue, so a brand blue stays a blue. The new colour is set immediately before the text and the original restored immediately after, so nothing painted later inherits it. Two checks gate the result: every pixel that changed must fall inside the text we recoloured, and the contrast check must afterwards report fewer failing runs. Symbol fonts - map markers, dingbats, icon fonts - are never recoloured, because those glyphs are pictures rather than text. You can replace any colour we chose with your own, or undo the recolouring entirely and keep every other repair; either way the document is re-checked and re-scored, so the figure you are shown always describes the file you would download.

Picture descriptions are drafted by AI and applied only where a person approved them. This is the one part of the product that sends any content to a third party, it happens only on request, and the drafts are proposals until someone reads them. A picture marked as decoration is not given empty alternative text: its content becomes an artifact and its figure leaves the structure tree, so assistive technology skips it entirely.

A description never silences text that is already in the document. In a PDF, alternative text replaces the element it is written on and everything inside it. Auto-tagging tools routinely group a caption into the figure it captions, so writing a description onto that figure would hand a screen reader one sentence about the picture and take away the caption underneath it - text still visible to everyone else, and a loss no score would report, because the figure now counts as described. Where the caption can be moved out to sit beside the figure it is moved, and both survive: the picture gets its description and the caption keeps its words. Where it cannot be separated, the picture is left undescribed and the reason is shown, because a missing description is visible to the next check and buried text is not.

Characters are mapped to Unicode where the mapping is known rather than guessed. A font with no character map leaves a reader's software to infer what each byte means, which is why copying text out of some documents produces rubbish and why a screen reader can be left with glyph codes instead of letters. Where a font declares one of the standard encodings, the specification fixes what every byte means, so the map we write is transcribed from that table rather than inferred from the document. A font whose encoding cannot be resolved that precisely is left alone and reported: a wrong map corrupts the text a screen reader reads out while making the problem look fixed to every checker. Writing a map cannot change how a page looks.

Broken tables are reported, never rewritten. A table is checked against what is actually drawn on the page - ruling lines and the alignment of text - and where the tags disagree with the table a sighted reader sees, the document is named as needing a person. What a column means depends on what it says, and a guess there reads as confident nonsense.

Finally, where the re-check finds a repaired document conforming to PDF/UA-1 in every respect, the PDF/UA identifier is written into its metadata and the file validated again. Where anything else still fails, it is deliberately left out: the identifier is a claim of conformance, and a false claim is worse than a missing one.

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.