Real User Monitoring for Accessibility
A small script runs axe-core and focus checks inside your visitors' real sessions, then ranks the accessibility barriers they actually met by how many sessions each one stopped.
Ranked by measured impact over the last 30 days1,240 sessions sampled
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What is real user monitoring for accessibility?
Web performance teams split measurement in two: lab data, gathered by loading a page in a controlled environment, and field data from the people who actually visit — which, as web.dev, 2022 puts it, is also known as Real User Monitoring. Real user monitoring for accessibility applies the same split. Instead of testing pages you chose in a browser you control, it checks for accessibility barriers inside real visitors' sessions and reports which ones they met, and how often.
How it works
- Add one script tag — or the next/script snippet for a Next.js app. The loader is 2 KB or less gzipped.
- Sessions are sampled. Paid plans sample 5% of sessions by default and can go up to 100%, within a ceiling of about 300,000 sampled sessions a month per domain. Only a sampled session downloads the engine, during browser idle time.
- Checks run in the visitor's browser: axe-core rules for WCAG 2.0, 2.1 and 2.2 at Levels A and AA, plus observers for focus traps, focus lost after route changes, invisible focus and dead-end Tab presses.
- Findings are redacted and ranked. The server strips anything outside the allowlist, and the dashboard ranks each barrier by the share of sessions that met it.
What monitoring catches that scans and scripted journeys cannot
Scans and journeys test the paths you know about. Real sessions include the ones you did not.
States no crawler reaches
Logged-in pages, a form half-filled, the error a real visitor triggered, the results of a search nobody scripted. The check runs on the page each visitor actually had in front of them.
What third-party code and personalization render
Chat widgets, consent banners, recommendations and A/B variants differ from one visitor to the next. A scan sees one version; monitoring sees the ones people got.
Focus behaviour in real use
Focus traps a keyboard user cannot leave, focus dropped to the page body after a single-page-app route change, focus that is not visible, and repeated Tab presses that go nowhere.
WCAG 2.1.1 · 2.1.2 · 2.4.3 · 2.4.7
The conditions a finding happened in
Viewport size, zoom level and root font size travel with each finding, so a reflow problem at 200% zoom is attributable to the visitors who were actually zoomed.
How many people each barrier stops
Every barrier is ranked by the share of sampled sessions that met it, with a 95% confidence interval, and keyboard-driven sessions are counted on their own.
Pages you did not know you had
Routes visitors reach that no sitemap or crawl found are surfaced, so scanning and journeys can cover them too.
Privacy and data handling
Monitoring runs on your visitors' sessions, so what it does not collect matters as much as what it does. The beacon beside this is the whole wire format.
- No page text and no form values ever leave the browser. Where text matters to a finding, only a measurement of it is sent: its length, its word count, and whether it matches a known-bad pattern.
- No full URLs. Only the route path is recorded; everything from the first query string or fragment onwards is cut, in the browser and again on our server.
- Attributes on an allowlist only, re-applied on our server independently of the collector, so an attribute a hand-crafted request tried to smuggle through is still dropped.
- Nothing about who the visitor is. No assistive-technology or disability detection. The only classification is behavioural: a session that moves by keyboard with no pointer input counts as keyboard-driven.
- No cookies. The collector keeps its sampling decision and its seen-set in sessionStorage, which is cleared when the tab closes, and sends batches with the browser’s own beacon transport.
- Nothing on your page is changed. It is a diagnostic, not an overlay: no injected ARIA, no rewritten markup, no toolbar. Its whole footprint is the one script tag the loader inserts.
Deploying it: the loader inserts the engine script from the same origin it was served from, so a site with a strict Content-Security-Policy needs that origin allowed in script-src. A visitor whose session is not sampled downloads nothing beyond one small configuration request. The full detail is on privacy and security.
{
"k": "acc_rum_…", // site key, public by design
"ctx": { "vw": 1280, "vh": 720, "dpr": 2,
"zoom": 1, "fontPx": 16,
"navigationMode": "keyboard-driven" },
"findings": [{
"rule": "axe:label",
"impact": "critical",
"wcag": ["4.1.2"],
"p": "/checkout", // path only — ?query and #hash stripped
"el": {
"tag": "input",
"attrs": { "type": "text" }, // allowlist only
"text": { "length": 0, "words": 0, "knownBad": false }
},
"n": 1
}]
}No page text and no form values: where text matters to a finding, only its length, word count and whether it matches a known-bad pattern are sent. The server re-applies this same policy to every beacon it receives.
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What monitoring cannot tell you
Monitoring widens where checks run, not what a machine can decide. It cannot judge whether alt text describes an image, whether a heading means anything, or whether a task can be completed end to end — that last one is what journey testing is for. For how the pieces fit, read the three layers of accessibility testing, and for the lab-and-field comparison in depth, real user monitoring vs. synthetic testing.
Sources
- Why lab and field data can be different (and what to do about it) (opens in a new tab). web.dev, July 18, 2022.
Frequently asked questions
What is the difference between real user monitoring and synthetic accessibility testing?
Synthetic testing — scans and scripted journeys — checks pages you choose, in a browser you control, at a time you pick. Real user monitoring checks the pages real visitors load, in their own browsers, in whatever state they reached. Synthetic testing tells you what could go wrong on a known path; monitoring tells you what did go wrong, for whom, and how often.
Does the monitoring script slow my site down?
The loader is 2 KB or less gzipped. The engine that carries axe-core is downloaded only for sessions selected by sampling, and injected during browser idle time; an unsampled visitor costs one small configuration request per session. Paid plans sample 5% of sessions by default.
Does it detect screen reader users or people with disabilities?
No, and it never will. Identifying assistive technology or disability is unreliable and treated by the accessibility community as surveillance. The only classification is behavioural: a session that moves by keyboard with no pointer input is counted as keyboard-driven.
What data does it collect?
The route path of the page (query strings and fragments removed), the accessibility rule or behaviour that failed, the structure and an allowlist of attributes of the element involved, and the viewport, zoom and font-size context. It never sends page text or form values.
Does it change or fix my pages?
No. It is a diagnostic, not an overlay: it never injects ARIA, rewrites markup or adds a toolbar. Its entire footprint on your page is the one script tag it loads. Fixes happen in your code, where they last.
Is real user monitoring free?
Yes. It is included on every paid plan, with 400 days of history, and available on its own on the free Monitor plan — one domain, no card, no expiry, 30 days of history.
See which barriers your visitors actually hit.
Monitoring is free on every plan, and on its own with Monitor — no card, no expiry.