Automated scans
Tools like axe check the code against rules: missing labels, low contrast, elements you can’t reach by keyboard. Fast and repeatable, but they only catch what a rule can express, and they can’t say who is affected.
Accessibility analytics: measuring whether your product works for everyone
An audit tells you whether your code meets WCAG. It can’t tell you whether people using a keyboard or large text actually finish checkout. Accessibility analytics measures that from real usage, by comparing people who use accessibility settings with people who don’t. This guide covers what you can measure, what you can’t and shouldn’t, and how to read the numbers.
Task: Checkoutbloom.shop · last 30 days
Attempts14,320
Success68%
Widest gap33 pts
| Setting | Attempts | Success | Gap |
|---|---|---|---|
| None (baseline) | 11,840 | 71% | — |
| Reduced motion | 640 | 70% | −1 |
| Large text | 1,190 | 58% | −13 |
| Keyboard | 912 | 38% | −33 |
Keyboard users finish checkout at about half the rate of people using no settings. That gap is the number to take to planning.
Three ways to know whether your product is accessible
Each answers a different question. None of them replaces the others.
Audits and research
An expert audit maps the product against WCAG. Testing with disabled people shows why something is hard. Both are essential, and both are snapshots of a product that keeps changing.
Accessibility analytics
Real usage, every day, split by accessibility setting. It answers how many people fall behind, where, how much it costs and whether the last release made it better or worse.
What you can measure: settings, not people
Browsers and operating systems expose the settings people choose: larger text, reduced motion, high contrast. Some behaviour, like navigating by keyboard, can be observed directly. Those are the raw material.
What you can’t measure is disability, and you shouldn’t try. Plenty of people use large text because their phone is small, and plenty of disabled people use no setting at all. Settings tell you how someone is using your product, which is what a fix needs to know.
| Setting | Where | How it’s detected |
|---|---|---|
| Keyboard navigation | Web, iOS | Web: five Tab presses, once Tab outnumbers pointer presses. iOS: a hardware keyboard or Switch Control |
| Zoom | Web | Page pinch-zoomed past 105% |
| Large text | Web, mobile | Browser default font above 16px; system text size above the default |
| High contrast | Web, mobile | prefers-contrast, or the system setting |
| Forced colours | Web | forced-colors: active, such as Windows contrast themes |
| Reduced motion | Web, mobile | prefers-reduced-motion, or the system setting |
| Reduced transparency, inverted colours | Web, mobile | Media queries, or the system setting |
| Bold text, grayscale | Mobile | The system setting |
| Screen reader | Mobile only | VoiceOver and TalkBack state. Browsers don’t expose it |
Browsers deliberately hide whether a screen reader is running, because exposing it would single out disabled visitors. Don’t try to infer it. Sustained keyboard navigation on the web covers many screen reader users and many people who don’t use one.
The method: compare against people using no settings
An accessibility gap is a difference between groups, so the comparison matters more than any single number.
Pick a task
Choose something with a clear start and finish that matters to the business: sign up, check out, book, finish onboarding. Give it a time window, like 30 minutes.
Split by setting
Measure success rate and time on task for each setting, and for people using none. Compare with that baseline, not the overall average, which already includes the groups you’re testing.
Wait for enough attempts
A gap on 20 attempts is noise. By default Metrickle won’t give a verdict on a group with fewer than 30 attempts, and shows the count so nobody reads too much into a small one.
Find the step
Filter the funnel to the group that falls behind. The step where their drop-off departs from the baseline is where the barrier is. Friction hotspots on that step usually name the element.
Hear it from them
Read barrier reports from that page, and show a one-question survey only to people with that setting. Ask about the task, never about disability.
Reading the numbers honestly
Accessibility numbers get quoted in planning meetings and sometimes in legal correspondence, so they need to survive scrutiny.
- Settings overlap. One person can have zoom and keyboard navigation on. Groups aren’t mutually exclusive, so they don’t add up to a total.
- Settings travel with other things. Large-text users may skew towards older devices. If a gap looks large, check it holds within one device type before calling it a layout bug.
- Say “keyboard users”, not “disabled users”. Report what was measured. It’s accurate, and it points at the fix.
- A small gap isn’t a pass. A group that’s 8 points behind on few attempts is a group to watch, not a group to declare fine.
- Look after the conversion too. A barrier in onboarding or account settings costs retained customers, not just first orders.
Checkout, since v4.12bloom.shop
| Setting | Attempts | Verdict |
|---|---|---|
| Reduced motion | 640 | Holding |
| Large text | 1,190 | Watch |
| Forced colours | 12 | Too few to judge |
| Keyboard | 912 | Broken |
Forced colours has 12 attempts. It isn’t green. By default it stays unjudged until there are 30.
Turn a gap into a priority
Backlogs are ordered by impact, and accessibility work often loses that argument because nobody has the number. The gap gives you one.
If 912 keyboard users start checkout each month and succeed at 38% against a 71% baseline, closing the gap is worth about 300 orders a month. At a £42 average order, that’s roughly £12,600 a month: a number a product manager can weigh against anything else on the list.
Regulation adds to it. The European Accessibility Act has applied to many consumer products and services since June 2025, and the ADA and Section 508 apply in the US. Evidence of how disabled people actually get through your product, release after release, is stronger than a single audit PDF. Ask your legal advisers what you need for your situation.
Connect the scan to the impact
Scanners produce long lists, and teams struggle to know which violation matters. Analytics produces gaps, and teams struggle to know which line of code causes them. Put them together and both problems shrink.
Metrickle accepts axe-core results uploaded from CI and attaches each violation to the page and element it was found on. When a friction hotspot and a violation land on the same element, the violation comes with a count of the people it’s stopping.
- Fix in order of impact, not in the order a scanner lists them.
- Catch what scans miss: a gap with no violation behind it points to a problem only real use reveals, like a confusing flow.
Hotspot: /checkout/slotbloom.shop · last 30 days
| Evidence | Detail |
|---|---|
| Friction | div.slot-day dead clicks in 1,140 sessions |
| Who | Keyboard users abandon here 3.4× as often as people using none |
| Scan | Serious: element is clickable but not focusable (WCAG 2.1.1) |
| Feedback | 2 reports: “Can’t pick a delivery day without a mouse” |
The scan found the bug. The analytics priced it. Same element, four kinds of evidence, one ticket.
Do it without singling anyone out
Never ask about disability
Record the settings a device reports. Don’t add questions, sign-up fields or surveys that ask people to disclose.
Report groups, not people
Use settings for breakdowns and filters, the way you’d use device type. Don’t build audiences or target marketing at them.
Let policy switch it off
If your privacy policy needs it, Metrickle’s web SDK takes a11y: false. Cookieless mode records settings with nothing stored on the device.
Common questions
What is accessibility analytics?
Measuring how well people using accessibility settings, such as keyboard navigation, zoom, large text or a screen reader, get through your product compared with people using none. It uses ordinary analytics events with the device’s settings attached.
Can I detect screen reader users on my website?
No, and you shouldn’t try. Browsers deliberately don’t expose it. Sustained keyboard navigation is a useful, honest proxy. Mobile apps can read the VoiceOver and TalkBack setting from the operating system.
How many users do I need before the numbers mean anything?
It depends on the size of the gap, but a few dozen attempts per group is a sensible floor. By default Metrickle won’t give a verdict below 30 attempts and keeps the group visibly unjudged until then. On low-traffic flows, look at a longer period.
Is accessibility setting data sensitive personal data?
Settings aren’t a record of health or disability, and Metrickle never infers why a setting is on. They can still feel personal, so treat them carefully: report in groups, don’t target individuals, and check your obligations with whoever advises you on privacy law.
Does accessibility analytics replace an audit?
No. An audit tells you what fails a standard. Testing with disabled people tells you why something is hard. Analytics tells you how many people fall behind, where, and whether a fix worked. Use all three.
Which settings should I look at first?
Keyboard navigation and large text. They’re common, and they break the most layouts: unfocusable custom controls, and text that overflows or clips at bigger sizes.
Find out who your product fails, and what it costs
Every event carries the device’s accessibility settings, with nothing to tag. Free to start.
Start free