/mobile-accessibility

name: mobile-accessibility
description: >-
  Make a mobile app driveable AND auditable through the accessibility tree, the
  shared dependency behind every tap-by-label interaction. One tree, two consumers
  reading different fields: driving reads the stable handle (testID ->
  accessibilityIdentifier); auditing reads the user-facing semantics (label, role,
  state, focus order). Covers iOS-native (UIAccessibility) and React Native / Expo
  (accessibilityLabel/role/state/accessible + testID) and how RN maps to the native
  tree. Prefer accessibility over coordinates. Referenced by ios-simulator and
  expo-ios-simulator for driving, and by the auditing skills for completeness.
status: complete
sources:
  - https://reactnative.dev/docs/accessibility (the React Native accessibility props)
  - https://reactnative.dev/docs/view (testID: "Used to locate this view in end-to-end tests")
  - https://developer.apple.com/documentation/uikit/uiaccessibilityidentification/accessibilityidentifier (the automation handle, distinct from the label)
  - https://developer.apple.com/documentation/uikit/uiaccessibilityelement/accessibilitylabel (the user-facing name)

Mobile Accessibility (the shared trunk)

Why its own skill: the same tags serve two consumers (driving vs auditing); owning them here keeps both DRY. Driving skills read the handle; auditing skills read the semantics.

The model: one tree, two readers

An accessible app exposes an **accessibility tree**: a hierarchy of elements that assistive technology (VoiceOver) navigates, and that an automation driver (AXe) reads to find and tap things. Every element can carry a few fields. Two of them matter most, and they exist for **different** reasons:

| Field (iOS) | React Native prop | Who reads it | What it is for | |---|---|---|---| | `accessibilityIdentifier` | `testID` | the **driver** | a stable **handle** to find an element in a script | | `accessibilityLabel` | `accessibilityLabel` | the **human** (VoiceOver) and the **auditor** | the element's **name**, spoken aloud |

Apple draws this line itself: an identifier lets a script *"uniquely identify an element"* and thereby *"avoid inappropriately setting or accessing an element's accessibility label"* (`accessibilityIdentifier` docs). React Native's `testID` is the same idea from the other side: *"Used to locate this view in end-to-end tests."* The label, by contrast, is *"a string that succinctly identifies the accessibility element"* for a user; Apple's example is "Save," not "Save button."

So:

• **Driving** wants the handle. Prefer `testID` -> `accessibilityIdentifier`; it does not

change when copy, locale, or layout changes. Tapping by visible label is the fallback when no handle exists. Coordinates are the last resort (brittle; see **ios-simulator** `references/driving.md`).

• **Auditing** wants the semantics: is there a label at all, is the role right, is the

state (disabled, selected, checked) correct, is the focus order sane.

Where to go

• iOS-native fields and how they surface to a driver: `references/ios-native.md`.
• React Native / Expo props and the RN -> native mapping: `references/react-native-expo.md`.
• The auditing lens (completeness, correctness): `references/auditing.md`.

Rules

• Prefer the **handle** (`testID`) for driving; fall back to the label; avoid coordinates.
• A label names; an identifier handles. Do not overload one for the other (Apple's own warning).
• Every factual claim here and in the references cites a primary source (Apple, React

Native, or AXe's own help); a prior-art skill is never a source.

Out of scope

Web a11y -> future web-accessibility. Cross-platform auditing -> future accessibility. Android specifics -> android-emulator-harness lineage.