Accessibility breakdowns
Last updated
Most analytics count people using accessibility settings in with everyone else, so a checkout that keyboard users can't finish looks like a small dip. Metrickle records which settings each visitor is using and compares them with people using none. You see who converts less, where they drop out, and what it costs.
Settings come from the device or browser. Nobody is asked, and Metrickle doesn't try to detect disability. 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.
What's detected
The SDKs detect settings automatically. What each platform can see differs, because browsers and operating systems expose different things.
| Setting | Label in the dashboard | Web | iOS and Android |
|---|---|---|---|
| Keyboard | Keyboard navigation | Five Tab presses, once Tab presses outnumber pointer presses | A hardware keyboard, or Switch Control (iOS) or Switch Access (Android) |
| Zoom | Zoomed in | The page is magnified with pinch zoom | Not detected |
| Large text | Large text | The browser's default font size is above 16px | The system text size is above the default |
| High contrast | High contrast | prefers-contrast: more | Increase Contrast or high-contrast text |
| Forced colours | Forced colors | forced-colors: active, such as Windows contrast themes | Not applicable |
| Reduced motion | Reduced motion | prefers-reduced-motion: reduce | Reduce Motion, or animations turned off |
| Screen reader | Screen reader | Not detected | VoiceOver or TalkBack is running |
Browsers deliberately hide whether a screen reader is running, so on the web Metrickle reports sustained keyboard navigation instead. That covers many screen reader users, and many people who don't use one.
Flutter and React Native read the same system settings as iOS and Android, with two differences on React Native: it doesn't detect keyboard use, and you pass AccessibilityInfo and the font scale to the SDK when you start it.
Depending on the platform, the SDKs also report Reduced transparency, Inverted colors, Grayscale and Bold text. A visitor can have several settings at once, and a setting turned on part-way through a visit is picked up from then on.
On the web, keyboard navigation is remembered for the rest of the browser tab's session. In cookieless mode nothing is stored, so it's detected again on each full page load. To stop collecting settings on the web, turn off the a11y option when you start the SDK. See the web SDK guide.
Where you see it
Overview
On the app's Overview, the Technology card has an A11y tab. It lists visitors by setting, including No a11y settings, with each one's conversion rate if you've set up goals. Select a setting to filter the whole page by it.
Friction
The Friction page has an Accessibility card. For each setting it shows sessions, the friction rate and the conversion rate, with the difference in points from sessions using no settings. Select a setting to filter by it. See friction.
Filters everywhere
Once you've filtered by a setting, funnels, journeys, retention and replays all show that group only. This is the quickest way to answer "where do keyboard users drop out of checkout?"
Protected flows
Every protected flow compares each setting with people using none after each release. A setting needs 30 attempts by default before it's judged. If it's more than 10 points behind, or its slowest 10% take 1.5 times as long, and the gap is clear of noise, the result is Gap found, naming the setting and the step where those users fall behind. Until it's clear, it's an Early signal.
When a protected flow breaks for a setting, the case is about those users: what they hit, on which element, and the recordings that show it.
A feedback report marked as an accessibility barrier takes back a completion from the same person within seven days. It counts against the setting that was on when the report was sent.
Research
- Studies show each task's success by accessibility setting.
- Surveys can be shown only to people using particular settings.
- Feedback reports and Replays list the settings in use.
See surveys and feedback and heatmaps and replay.
Portfolio
Portfolio answers "Can everyone finish your key tasks?" across all your apps, with each protected flow's latest result.
Accessibility scans from CI
Automated checkers find problems in the code, but can't say who they affect. Metrickle puts the two together. Post axe-core results from your CI to the app's scan hook, and each violation shows next to the friction on the same page or element.
To set it up:
- Open your app and select Integrations.
- Under Accessibility scans, select Set up scan hook.
- Copy the URL into your CI secrets. Anyone with it can replace this app's scan results.
- After each deploy to staging or preview, post the results from the axe CLI, or from Playwright tests using
@axe-core/playwright. The dialog shows examples of both.
Each page keeps only its latest scan, so a clean run clears it. View pages lists scanned pages with their critical, serious and total violations, worst first.
On the Friction page, a hotspot with a violation on the same element shows the finding, its impact and the WCAG criterion. Pages show their violation count, or "Not scanned".
Plans
Every plan includes the accessibility split. See pricing for what each plan includes.