Accessibility monitoring as a category has been reshaped in the last twenty-four months by three forces, and the buying decision in 2026 looks nothing like the buying decision in 2023. First, the European Accessibility Act became enforceable in June 2025, and the procurement waves that have followed across all twenty-seven member states have lifted the EU portion of the monitoring market well past the US for the first time. Second, the DOJ Title II 2024 rule hardened the US public-sector requirement and triggered a procurement cycle across state and local government that is still working through. Third, the field has finally absorbed the uncomfortable empirical fact that automated scanning, on its own, catches only somewhere between thirty and forty percent of WCAG 2.2 success criteria — which means picking a platform is now much less about “scanner accuracy” and much more about workflow. The question is how scan output becomes triage becomes remediation becomes a verified, defensible, publishable accessibility statement.

This guide is for the procurement officer, the engineering director, the chief compliance officer, and the accessibility lead who has been asked to shortlist platforms. It compares six named vendors across the criteria that actually decide the contract. Before any of that, though, it is worth being precise about what “accessibility monitoring” is and is not — because the vendors blur the categories on purpose. If you want a baseline number for your own site before you read further, the free Disability World scanner will give you one in under a minute.

The category is younger than its vocabulary suggests, and four distinct products are routinely sold under overlapping names. Separating them is the first useful step in any buyer conversation.

A scanner is a one-off URL check. You paste in a single page, the tool fetches it, runs a ruleset — usually axe-core or a derivative — and prints a list of violations. Browser extensions like axe DevTools, Lighthouse’s accessibility audit, the WAVE toolbar, and most free online scanners belong in this category. Scanners are commoditised. The underlying rulesets are mostly the same open-source engines under different skins, and the results across the major scanners on a given page rarely diverge by more than a few percent.

Monitoring is the continuous version. A monitoring platform crawls a site or an app on a schedule, builds a baseline, and then reports diffs as deploys land. Where a scanner answers “what’s wrong with this page?”, a monitoring platform answers “what changed since Tuesday?” — and that diff view is the thing the engineering organisation actually uses. Monitoring is what scales scanner output to a fleet of pages, a multi-property organisation, or a product surface that ships twenty times a day.

An audit is the manual review. A specialist — increasingly, a tester with a disability working with the screen reader they use every day — walks through the product end-to-end and reports the issues automation cannot detect. Keyboard traps, focus-order quality, screen-reader legibility, the actual meaningfulness of alt text, the behaviour of dynamic-content updates, the comprehensibility of error messages. Audit is the layer that catches the sixty-to-seventy percent of WCAG issues that scanners miss.

A statement or compliance dashboard is the published artefact and the workflow that produces it. Under the EAA, under the UK Public Sector Bodies regulations, under section 508 procurement, under the EN 301 549 framework, the buyer has to publish something — an accessibility statement that reads cleanly to a regulator, lists the conformance level, names the known issues, and dates the next review. A “compliance dashboard” is the internal-facing version that tracks the same posture for the executive team.

A monitoring platform — what this guide compares — is the product that stitches scanner output, continuous crawl, triage, optional manual audit, and statement generation into a single workflow. The scanner layer is commodity. The platform layer is where the differentiation lives, and the value of the contract.

Eight criteria separate the platforms in 2026. The vendors will not always volunteer the answers; ask anyway.

The single most diagnostic question. WCAG 2.2 became a W3C recommendation in October 2023 and adds nine success criteria — focus appearance, dragging movements, target size, accessible authentication, redundant entry, consistent help. Some vendors are still scanning against 2.1 and rebrand the dashboard as “2.2-ready” without supporting the new criteria. The honest answer is that most automated rulesets cover only a subset of 2.2 because several of the new criteria (e.g. accessible authentication, consistent help) are not amenable to static analysis. The platform should say which 2.2 criteria it covers automatically, which it surfaces for manual review, and which version of EN 301 549 it aligns its reporting to.

A platform that can crawl two hundred pages once a week is a different product from one that can crawl a hundred thousand pages on every deploy. The buyer’s crawl-frequency target should fall out of the deploy cadence. A marketing site that ships twice a week needs at minimum a nightly crawl; a product surface that ships continuously needs a CI integration that runs per-commit. The platform’s page-volume cap, depth-of-crawl limit, and concurrent-crawl limit decide whether the contract holds up at year three when the site has grown.

The line item that quietly multiplies the price. “PDF support” can mean any of three things. It can mean the platform detects PDF links and counts them, which is not a check. It can mean the platform extracts text and checks for an outline, a language declaration, and basic tagging, which catches a small fraction of PDF/UA failures. Or it can mean the platform runs a genuine PDF/UA validator against the document tree, which is what a defensible PDF compliance posture actually requires. Ask which.

Most modern product surfaces are SPAs behind a login. A crawler that cannot drive a JavaScript runtime and cannot maintain an authenticated session is a crawler that scans the marketing brochure and reports nothing about the application. The technical question is whether the platform uses headless Chromium with cookie injection or a saved-session token, how it handles SSO flows, and whether it can complete a multi-step OAuth dance. The procurement question is whether you have to set up that workflow yourself or whether the vendor’s onboarding does it.

Native iOS and Android apps fall under the same legal regimes as the web, and most monitoring platforms do not cover them. Vendors that do offer mobile scanning typically charge for it separately and use a different ruleset against the platform-specific accessibility APIs. If the buyer ships native apps, asking specifically about iOS UIAccessibility and Android AccessibilityNodeInfo coverage will quickly thin the shortlist.

Scan output that does not land in the engineer’s existing workflow gets ignored. The minimum integration set in 2026 is Jira, GitHub or GitLab, Slack, and a CI hook. The better platforms ship Linear, Azure DevOps, Microsoft Teams, and a webhook API. The integration question is not just “does it post a ticket” but “does the ticket carry the page URL, the violation code, the WCAG criterion, the suggested fix, and a reproducible selector or screenshot?”

The criterion that separates the platform tier from the scanner-with-a-dashboard tier. A real handoff workflow lets you select a set of pages, scope a review, brief a human auditor (in-house or vendor-provided), track the audit through review states, and bring the findings back into the same dashboard alongside the automated results. The presence or absence of this workflow is the single best predictor of whether the platform can support a defensible EAA or ADA compliance posture, because the manual layer is non-negotiable under both regimes.

EAA Article 13 requires an accessibility statement published in a machine-readable form. The UK and EU public-sector regulations require one. The DOJ Title II rule expects one. The platform should produce a statement artefact — a published-quality document, not just a dashboard screenshot — that names the conformance level, lists known issues, dates the audit, and updates as the monitoring data changes. The vendors that treat this as a first-class output save the buyer a meaningful amount of legal-counsel time at renewal.

The scan dashboard the engineering team uses is not the dashboard the CFO or the audit committee wants. The platform should produce both — an engineering-grade triage view with selectors and code snippets, and a board-ready view that reports issue counts by severity, deploy-over-deploy trend, conformance percentage by property, and projected close dates. Platforms that only ship one of the two end up bolted onto a separate BI tool, which adds cost.

The pricing model itself is a signal. Per-domain pricing is honest about scope. Per-page pricing scales with the buyer’s growth and tends to be expensive. Per-scan pricing rewards efficient crawling. Per-user pricing is a soft cap that gets gamed. The split between transparent published pricing and sales-call-only pricing is a market division: most enterprise vendors hide pricing behind a quote, while the engineering-led tools publish a tier. A vendor that will not name a starting price on the discovery call is signalling that the contract will be larger than the buyer expected.

The six platforms below cover the working enterprise shortlist in 2026. The fair-comparison table sits first, with the per-vendor narrative below.

For teams whose situation is different, the fair shortlist runs as follows. A pure engineering shop with a strong CI/CD culture and an accessibility lead who lives inside the developer toolchain will be better served by axe Monitor, because Deque’s strength is the engineering experience and the per-deploy regression view. A marketing-led organisation where the accessibility budget sits inside the digital experience team alongside SEO and content quality will be better served by Siteimprove, because the marketing-grade dashboards are the centre of that product and the cross-module reporting matters. An enterprise with heavy US litigation exposure and a general counsel who wants the legal-defence narrative front and centre will be better served by Level Access, because the in-house audit practice and the VPAT and expert-witness infrastructure are the deepest in the market.

None of these is a bad choice for its use case. The wrong choice is the platform that fits a different organisation’s situation than yours. Run the procurement against the criteria above before the demo, not after.

The most important honest caveat in any monitoring conversation. Automated scanning catches roughly thirty to forty percent of WCAG issues under generous assumptions. The remaining sixty to seventy percent require human judgement — and no amount of additional rule development is going to close that gap, because the things automation misses are categorically not amenable to static analysis.

Automation cannot judge whether alt text is meaningful — it can only check whether alt text exists. A photo of a person captioned “image” passes the automated check and fails the user. Automation cannot detect a keyboard trap in a custom widget unless the trap is structural rather than behavioural. Automation cannot evaluate focus-order quality — it can flag missing focus indicators, but it cannot tell you that the focus jumps illogically across the page. Automation cannot test screen-reader legibility against the real assistive-technology stack — what NVDA, JAWS, VoiceOver, and TalkBack actually announce on a given component is something only a human can verify. Automation cannot judge whether a dynamic-content update is announced to a screen reader; it can check for aria-live attributes, but not whether they fire at the right moment. Automation cannot test sign-language interpretation, cognitive-accessibility readability, the comprehensibility of error messages, the navigability of a complex form by a switch-control user, or the colour-contrast of text rendered against a video background.

This is the layer the monitoring dashboard cannot speak to. A site can have a green automated scan and be unusable end-to-end by a screen-reader user, and the failure mode is so common that it has its own shorthand in the field: the gap between conformance and accessibility. The platforms that acknowledge this — and that build the manual-audit handoff into the workflow — are doing right by the buyer. The platforms that sell automated scanning as “compliance” without the audit layer are selling a posture that will not survive contact with a real assistive-technology user or, increasingly, with a regulator who has been to the seminar.

Print this list. Bring it to the demo. Refuse to schedule the follow-up call until every answer is in writing.

Vendors who answer every one of these clearly and in writing are vendors whose contract is straightforward. Vendors who push back on the questions are signalling that the relationship will involve more discovery later than the buyer wants.

No. Monitoring is the continuous, mostly-automated layer that runs against a site or app and reports regressions as they appear. An audit is a point-in-time manual review by a specialist, usually including testers with disabilities, that catches the issues automation cannot detect — keyboard traps, focus-order quality, screen-reader legibility, meaningful alt text, dynamic-content updates. A defensible compliance posture needs both. The two layers answer different questions and neither substitutes for the other.

No, and any vendor that says otherwise is selling automated scanning as compliance, which it is not. Automated scanners catch roughly 30 to 40 percent of WCAG issues under generous assumptions — colour contrast, missing alt text, missing labels, document structure. The remaining 60 to 70 percent require human judgement. The best monitoring platforms acknowledge this and provide a workflow to hand scan output off to manual auditors; the worst pretend it isn’t an issue.

For a fast-moving product surface, on every deploy through CI, with a full crawl at least weekly. For a marketing site that ships twice a week, a nightly or per-commit crawl is the working rhythm. For a stable public-sector portal, a weekly crawl plus a per-deploy regression scan is usually defensible. The trap is treating compliance as a quarterly snapshot — every push is an opportunity to break a label, lose a focus ring, or ship a component that announces itself as a div.

No. Neither the US Department of Justice’s 2024 Title II rule nor the European Accessibility Act treats an automated scan report as evidence of conformance on its own. The DOJ rule names WCAG 2.1 Level AA as the substantive standard; the EAA references the harmonised EN 301 549, which itself references WCAG 2.1 AA. Both regimes contemplate a programme that combines automated monitoring, manual audit, and a published accessibility statement. A green scanner dashboard is necessary but not sufficient.

Enterprise list prices in 2026 typically run from approximately 15,000 to 120,000 US dollars per year, with the spread driven by domain count, crawl frequency, page volume, and whether manual audit hours are bundled in. Mid-market plans at roughly 6,000 to 18,000 dollars per year are common for the same platforms with smaller crawl caps. PDF accessibility, mobile-native scanning, and bundled manual audit are the three line items that move the price the most. Almost every enterprise platform requires a sales call to get a real quote.

Maybe not, if your scope is a single web property, your engineering org has the discipline to fail builds on axe regressions, and you have a separate manual-audit relationship for the 60 to 70 percent automation misses. Most organisations outgrow that pattern. A monitoring platform adds the crawl across pages no CI run touches, the executive-readable dashboard, the regression view across deploys, the PDF coverage, the statement-generation workflow, and — at the better end of the market — the manual-audit handoff. The question is workflow, not scanner accuracy.

At a minimum: WCAG version support, crawl frequency and page-volume caps, single-page-app and authentication handling, PDF accessibility (a real check, not file-type detection), mobile-native iOS and Android coverage, integration with the buyer’s issue tracker and CI, the manual-audit handoff workflow, a sample accessibility-statement output, executive and engineering dashboards, and the pricing model named explicitly — per-domain, per-page, per-scan, per-user. A vendor that resists transparent pricing is a procurement red flag.

Three concrete next steps. First, run the free Disability World scanner against your highest-traffic page and your most business-critical authenticated page to get a baseline number — this is the figure every vendor will ask you for on the discovery call, and it is more useful to have it before the call than during it. Second, if you have not already, read the European Accessibility Act, ADA Title III, and WCAG 2.2 success criteria primers, so the procurement conversation is grounded in the actual standards rather than the vendors’ marketing summaries. Third, shortlist two or three platforms from the table above based on the editor’s-pick framing and request demos — but run the procurement checklist as the agenda for the demo, not the vendor’s slide deck. The platform you buy is the platform you live with for at least three years; the hour spent on the criteria upfront is the cheapest hour in the whole project.