Accessibility audits

Switch a run to accessibility mode and Mini does its usual job, while every new screen it reaches is captured and audited against WCAG 2.2. You get a per-screen report you can hand to a developer, and a conformance table you can hand to an auditor. The run is not slowed down and Mini does not behave differently. The audit happens beside it, on screens Mini was already looking at.

​

Turn it on

Accessibility mode is a per-run option, next to the build and the stories you pick when you start a run. Your workspace has to be enabled for it first, so talk to us if you do not see it. Screens appear on the Accessibility page while the run is still going. An audit takes between a few seconds and a few minutes per screen, so the page fills progressively rather than all at once.

​

What a verdict means

Every criterion, on every screen, gets exactly one of five states. They are not interchangeable, and that is what makes the report hold up. Two rules follow from that table, and both are deliberate. Only a measurement produces a Pass or a Fail. Contrast ratios, touch target sizes, missing labels and roles are arithmetic, so they are decided without a model. When a measurement is not reliable, a contrast ratio over a gradient for instance, the row drops to Needs review with the cropped image attached rather than claiming a failure. Everything a model observes lands in Needs review. Mini reads the screen and proposes an answer for the criteria that need judgment, like whether colour alone carries meaning, but it never settles them. You do, and only then does the row count in the conformance table.

​

Reading the map

Each card is one screen, named the way Mini named it. A screen can hold several states: an empty form, the same form showing errors, a list before and after it loads. Each state is audited on its own, because an error message that nobody can read is a real defect on a real screen. A list does not create a new state every time its contents change. Two screens count as the same when their structure matches, so a catalogue with different products on every visit stays one screen. The keyboard, the status bar and system permission dialogs are skipped. They belong to the phone, not to your app.

​

Reading a screen

Open a card and you get the screenshot with the offending elements boxed, and one row per criterion beside it. Each row carries what was measured against what was expected, in plain numbers: 3.2:1 measured, 4.5:1 required, or 20x20 dp measured, 24x24 required. It also carries the element’s technical identifier, so a developer can find it without replaying the run. Rows that need your decision have two actions. Confirm marks the issue as real, and the criterion counts as failing. Not an issue dismisses it, and it counts as passing. Until you pick one, the row is reported as awaiting review and does not move the outcome either way.

​

Reading the conformance table

One row per criterion, with the outcome an audit report expects: supports, partially supports, does not support, not applicable, not evaluated. Underneath, the count of screens in each state and the screens that fail. The table also shows what changed since the previous audited build: new failures, fixed, still failing. That comparison only holds between two runs judged on the same list of criteria, so when the list changed, the table says so instead of showing a delta that would read as regressions.

​

What is not checked, and why

Some criteria cannot be judged from a run on a phone, and the report names each one rather than staying silent. Anything needing an external keyboard or switch control, anything about timing and moving content, and captions on media fall in that group. Criteria that need the app rendered differently, at 200% text size or in landscape, need a run in that configuration and are reported as such. Read the absence of a criterion as nothing. Read Not checked as the honest answer it is meant to be.

​

The limits worth knowing

The audit covers the screens Mini visited during that run. A screen no story reaches is never audited, so widening the suite widens the report. An accessibility report is not a legal certificate. It is evidence you produce continuously, in the shape an audit expects, and it is only as complete as the journeys behind it.