Put a number on every accessibility barrier
Every event Metrickle records carries the accessibility settings seen on the device. Compare any task, funnel or journey against people using none, and take evidence to the backlog instead of a hunch.
| Setting | Chart | Success | Median time |
|---|---|---|---|
| None | 78% | 1m 31s | |
| Reduced motion | 76% | 1m 35s | |
| Zoomed in | 64% | 2m 20s | |
| Large text | 61% | 2m 07s | |
| Keyboard | 44% | 3m 02s |
Keyboard users are the furthest behind: 44% succeed, 34 points below people using none, and those who finish take twice as long.
From “is this accessible?” to a ticket with numbers
A walkthrough on bloom.shop, a demo app with sample data. The same views work on your own apps from the first day of data, with nothing to set up beyond the script tag or SDK.
Compare
Open any task or funnel and split it by accessibility setting. Success rate, time on task and drop-off sit next to the baseline of people using none.
Locate
Filter the friction report and journeys to the group that falls behind. The dead clicks, u-turns and form errors they hit are ranked by element and page.
Confirm
Read the accessibility barrier reports from the same page, ask a one-question survey shown only to that group, and watch consented replays of the attempts that failed.
Device settings on every event, with nothing to tag
The script tag and the mobile SDKs read the settings people already use and attach them to every event. On the web that means sustained keyboard navigation, zoom, large text, high contrast, forced colors, reduced motion, reduced transparency and inverted colors. On mobile it adds bold text, grayscale and the screen reader.
Browsers deliberately hide whether a screen reader is running, so the web reports keyboard navigation instead. The iOS, Android, Flutter and React Native SDKs read the real screen reader setting from the operating system.
- Settings, not diagnoses: Metrickle sees that large text is on, never why. Nobody is asked anything and nobody has to disclose anything.
- Stored like device type: a short list of flags per event, used for filters and breakdowns. Sessions with no flags form the “none” baseline.
- One filter everywhere: tasks, funnels, friction, journeys, surveys and replays all split by the same setting.
| Setting | Sessions | Friction | Converted |
|---|---|---|---|
| None | 41,730 | 12% | 9.4% |
| Bold text | 3,115 | 14% | 8.9% |
| Large text | 4,480 | 21% | 6.8% |
| Screen reader | 1,262 | 33% | 4.1% |
Screen reader sessions convert at less than half the rate of sessions with no settings, and a third of them hit friction on the way.
Find the step that fails one group and not the others
A barrier often hides inside a healthy average. Filter a funnel to one setting and the biggest-leak callout moves to the step that group can’t get past, even when everyone else gets through it fine.
Put the two numbers side by side and you have the cost of the barrier in lost signups, orders or bookings. That is usually what moves an accessibility fix up the backlog.
- Funnels and tasks by setting, with drop-off, median time per step and where abandoned attempts stopped.
- Journeys filtered to one setting, to see where people go when the intended path fails.
- Heatmaps come with a text summary and data tables, so the evidence itself is readable with a screen reader.
Biggest leak: Delivery → Slot (−62%)
The slot picker loses keyboard users. People using no settings lose 18% at the same step. The top hotspot is a dead click on the calendar grid.
Let people report barriers, and ask the right group
The always-on “report a problem” widget has an accessibility barrier category. Reports arrive in a triage inbox with the page, device, app version and settings attached, plus an optional screenshot that people can highlight or partly hide before sending.
Surveys can target accessibility settings, so you can ask keyboard or large-text users one question on the step that fails them, without asking anyone about disability. Answers are events, so they become filters on funnels and replays.
- Built to WCAG 2.2 AA: the survey and feedback UI uses native controls, visible focus, 44px targets and supports forced colors and reduced motion.
- Web and mobile: surveys and feedback run everywhere, with a built-in accessible survey sheet on iOS, Android and Flutter. Heatmaps and replay are web-only for now.
| Report and page | Setting |
|---|---|
“Can’t pick a delivery day without a mouse” /checkout/slot | Keyboard |
“Price covers the button when text is bigger” /basket | Large text |
“Selected size isn’t visible” /plants/fern | Forced colors |
Two reports name the slot picker the funnel flagged. Each arrives with page, device, app version and settings, so it’s ready to file.
Everything you need to make the case
Accessibility is a filter on the whole product, not a separate report. These are the pieces you’ll use most.
Tasks and research
Success rate, median and p90 time on task, and where abandoned attempts stop, for any setting.
Funnels
Drop-off and the biggest leak per setting, so you can price a barrier in conversions.
Friction report
Rage, dead and error clicks, u-turns and form errors, with friction and conversion rate per setting.
Targeted surveys
Show a question only to people with a given setting, on the page where they struggle.
Heatmaps and replay
Replays filter by setting. Heatmaps include a text summary and data tables.
Barriers reach the team
Accessibility barrier reports go to Slack or Teams with the reporter's settings, and become issues measured after the fix.
Ask Claude
Ask an AI assistant over MCP which checkout step loses the most keyboard users.
Common questions
Can Metrickle tell whether someone uses a screen reader on my website?
No. Browsers deliberately hide it, and we don’t try to guess. On the web Metrickle reports sustained keyboard navigation instead, which many screen reader users also produce. The mobile SDKs read the screen reader setting from iOS and Android directly.
How is keyboard navigation detected?
A session counts as keyboard-driven after five Tab presses, once Tab presses outnumber pointer presses. It’s remembered for the rest of the browser tab’s session, except in cookieless mode, where nothing is stored and it’s detected again on each page load.
What do “zoomed in” and “large text” mean?
On the web, zoomed in means the page is pinch-zoomed past 105%, and large text means the browser’s default font size is set above 16px. In the mobile SDKs, large text means the system font scale is above 115%.
Is this sensitive data about disability?
Metrickle records device settings, the same way it records screen size or browser. It never asks about disability and can’t infer why a setting is on. If your policy needs it, pass a11y: false to the web SDK to switch capture off.
Does this replace an accessibility audit or testing with disabled people?
No. An audit tells you what fails a standard, and research with disabled people tells you why something is hard. Metrickle tells you where real users fall behind and how much it costs, which helps you choose what to fix first and prove the fix worked.
See where your apps break, and who they break for
Free to start. One script tag on the web, one SDK on mobile, and no cookie banner in cookieless mode.
Start tracking for free