Mobile accessibility
Skill simiancraft/simiancraft-skills/skills/mobile-accessibility
Public Claude Code skills and agents from simiancraft. Marketplace-installable.
npx -y skills add simiancraft/simiancraft-skills --skill mobile-accessibilityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.7 KB, as published. Nobody here has run it
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-simulatorreferences/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.