Skip to main content
mobster test --a11y audits each screen your checks visit, from the accessibility tree Mobster already reads. It calls no model, sends nothing off your Mac and adds one tree read per step, about a second on a simulator (measured 28 Sep 2026: 0.8 to 1.6 s). A screen it has seen is audited once.
A check turns it on by itself with a11y: warn or a11y: strict in its file. --a11y applies to every check; a check that says strict stays strict. The older audit: a11y also stays strict.

​
The rules

text-clipped reads frames, not pixels. Text that truncates inside a frame of the right size isn’t found, so a clean run is not proof that Dynamic Type works. Mobster doesn’t audit colour contrast. The tree has no colours, and the pixels of a screenshot under translucent bars, images and gradients don’t give a foreground and background you can trust, so a number would be a guess.

​
Warnings, failures and the baseline

Each finding has a level in results.json:
  • warn: reported, the check passes. This is the level of --a11y.
  • fail: with --a11y=strict, the check fails with reason.class finding.
  • known: the finding is in the project’s baseline. It is listed and never fails.
A project with existing problems starts clean by recording them:
Commit .mobster/a11y-baseline.json. From then on mobster test --a11y=strict in CI fails only on a finding that isn’t in it:
A baseline entry is a JSON-encoded tuple of the check’s file, the rule, and the element’s role, label and identifier. It ignores the element’s position, so a layout shift doesn’t make an old finding new. Fix an element and its finding disappears; the next --update-a11y-baseline drops its entry. A baseline file that isn’t valid stops the run. Pass --update-a11y-baseline to replace it with the current findings.

​
Where findings go

  • results.json: each device result’s findings lists id, audit, guideline, level, key, message, the element (role, label, identifier, rect in points) and the frame of the screen.
  • The HTML report: a tag in the header counts new findings, warnings and baseline entries, and each check’s page lists its findings with the frame.
  • junit.xml: one extra <testcase> per finding in the device’s <testsuite>, named <check>: <rule>, <element>. A fail finding has a <failure type="accessibility">; a warn finding passes and carries Warning: … in <system-out>; a known finding gets no case.
  • The terminal: one Accessibility: line after the counts.
This page’s commands run on simulators and on --device iPhones. mobster test pr doesn’t take --a11y; put a11y: in the checks it runs.