Accessibility audits

Turn on the accessibility audit for a run and Mini tests your scenarios as usual, while every new screen it reaches is captured and checked against WCAG 2.2. You get a per-screen list of findings a developer can act on, and a conformance report you can hand to an auditor. The checklist each app is judged on lives in App settings → Accessibility checklist.

​

Choose what to check

Before the first audit, the app needs a checklist. Open Results → Accessibility: until there is one, the page shows Set up accessibility testing in two steps. From the list of standards, you can also start your own list:

• Customize first: untick what doesn’t apply, then Use N criteria.
• Copy from another app: reuse the published list of an app in the same workspace.
• Import a document: give Mini your own checklist. It drafts the list and shows it in the chat, with how many rows it couldn’t match to WCAG, then you Publish it or Open in editor.

Only workspace owners and admins can choose or change the checklist.

​

Run an audit

In Run tests, turn on Accessibility audit in the run’s options: it “checks every screen against WCAG while the scenarios run.” The run needs at least one iOS or Android target. Under the option, the dashboard names the checklist the audit uses, with Change to go to it. The run isn’t slowed down, and Mini doesn’t test any differently. Screens show up on the Accessibility page while the run is still going, and the page fills in as each screen is audited. A screen identical to one already audited in the run isn’t audited twice.

​

Read the results

Results → Accessibility opens on the app’s latest audited run. Pick another audited run from the list, switch between All, iOS and Android when the run covered both, and use Open run to go to the run itself. The audit has two views: Screens and Criteria.

​

Every check has one state

Only a measurement decides a result on its own. Contrast ratios, touch target sizes, missing labels and roles are checked automatically on every screen. Criteria that need judgment, like whether color alone carries meaning, are reviewed by Mini, and what it finds lands in To review until someone decides.

​

A screen

Each card on the Screens view is one screen. Open it for the screenshot with the offending elements boxed (All boxes shows every finding at once) and the findings beside it, grouped Non conform, To review and Conform. A screen captured more than once lets you step through its captures. Each finding says what was measured against what was required, in plain numbers, like 3.2:1 measured, 4.5:1 required or 20x20 dp measured, 24x24 required, and names the element so a developer can find it without replaying the run. On a finding to review, pick Issue to confirm it, and it counts as non conform, or Dismiss to set it aside. The row then reads Confirmed or Dismissed. Copy for agent copies the screen’s findings as a brief for Cursor or Claude Code.

​

The conformance report

The Criteria view gives one row per criterion of your checklist, with the outcome an audit report expects: Supports, Partially supports, Does not support, Not applicable, Needs review or Not evaluated, and the screens behind it. It also shows what changed since the previous audited build: new non conform, now conform and still non conform. When the checklist changed between the two runs, the comparison uses only the criteria both versions share, and says so. The app’s first audited run has nothing to compare against. Two groups sit apart from the outcomes:

• To verify yourself: lines of your checklist Minitap doesn’t check, listed for your team.
• Outside your list: what Minitap saw on criteria your checklist leaves out. None of it counts in the outcomes, the coverage or the changes.

Share copies a link to the audit or exports the Accessibility conformance report as a PDF.

​

Change the checklist

App settings → Accessibility checklist shows what the app’s accessibility runs are checked against: the standard it’s based on, the version, how many criteria, who published it and when, and who checks what (for example “10 checked automatically · 18 reviewed by Mini · 18 to verify yourself”). View criteria lists them. History lists every published version, with what changed and the runs judged on it. Published versions can’t be edited or deleted. When your standard publishes a new version, a notice says so: See changes shows the difference, and Start a draft from that version begins a new revision. Your edits to the current version aren’t carried over. Change standard…, in the list’s menu, starts again from another standard.

​

The limits worth knowing

The audit covers the screens Mini visited during the run. A screen no scenario reaches is never audited, so a wider suite gives a wider report. Some criteria can’t be judged from a run on a phone, like those that need an external keyboard, and the report marks them Not checked instead of leaving them out. Criteria that need the app shown with other display settings, such as larger text, need a run in that configuration. An accessibility report isn’t a legal certificate. It is evidence you produce on every audited run, in the shape an audit expects, and it is as complete as the journeys behind it.

​

Next steps