Install
$ agentstack add skill-simiancraft-simiancraft-skills-mobile-accessibility ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
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.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: simiancraft
- Source: simiancraft/simiancraft-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.