iOS accessibility: the rules

The Android counterpart is wcag-mobile-rules (criteria catalogue in packages/a11y/src/appscreenmap/a11y/wcag.py); this page is what changes on iOS. WCAG 2.2 still decides pass/fail; Apple's HIG sets stricter numbers in places. Say which one a finding used.

The iOS accessibility tree is the evidence

The crawler reads what idb ui describe-all returns (see ios-simulator): the same tree VoiceOver walks. So:

• A control that isn't in the tree can't be reached by VoiceOver, Voice Control, Switch Control or the crawler. That's the strongest iOS finding and it is detected for free: the crawl simply can't get there. A custom floating tab bar and an unlabeled close "×" are the typical examples.
• Per element the tree gives: AXLabel (the accessible name), AXValue, AXUniqueId (the accessibilityIdentifier; tests only, VoiceOver never reads it), type, traits (Button, StaticText, TextEntry, NotEnabled, Selected, Header…), frame in points, enabled, custom_actions. Order in the list is the VoiceOver reading order.
• Scrollable appears on nearly every node; ignore it.

Translating terms

Thresholds

What the crawler checks, by evidence

What needs a device or a person

VoiceOver announcements and gestures (magic tap, escape, custom actions), the Headings rotor, Voice Control commands ("Tap <name>"), Switch Control scanning order, Full Keyboard Access focus ring, Reduce Motion behaviour, captions and audio descriptions, cognitive criteria (3.3.7 redundant entry, 3.3.8 accessible authentication). Record these in the a11y audit's manual list (a11y-audit skill), not as automated findings.

Fixes (SwiftUI)

Button { … } label: { Image(systemName: "bookmark") }
  .accessibilityLabel("Save")                      // icon-only control: name it
Text("VOICE").accessibilityAddTraits(.isHeader)    // section title
Image("hero").accessibilityHidden(true)            // decorative
HStack { … }.accessibilityElement(children: .combine)   // one stop instead of three
Button { … }.frame(minWidth: 44, minHeight: 44)    // or .contentShape(Rectangle()) with padding
Text(title).font(.body)                            // text styles scale; fixed sizes don't
  .dynamicTypeSize(...DynamicTypeSize.accessibility3)   // cap only where the layout truly can't grow
view.accessibilityIdentifier("tab.following")      // stable id for tests and AppScreenMap; VoiceOver ignores it

A custom control built from onTapGesture is invisible to assistive tech: use Button, or add .accessibilityElement(), .accessibilityLabel, .accessibilityAddTraits(.isButton) and .accessibilityAction.

Adding an iOS rule

Follow add-a11y-rule. iOS runs have run.device.platform == "ios"; rules that read Android-only attributes (resource ids with /, activities, content-desc) must branch on it or be skipped. In the viewer (apps/viewer/src/a11y.ts) wording that differs by platform lives in the IOS overrides (read through useRules(), set by the run shell's PlatformCtx), and TARGET_MIN holds the per-platform target size (48 dp Android, 44 pt iOS). The translated XML puts AXLabel in text (or hint for fields) and AXUniqueId in resource-id as <bundle>:id/<id>. Test with a recorded tree (packages/drivers/tests/fixtures/ios-reader-home.json), never a device.