AgentStack
SKILL verified MIT Self-run

Mobile Accessibility

skill-simiancraft-simiancraft-skills-mobile-accessibility · by simiancraft

>-

No reviews yet
0 installs
14 views
0.0% view→install

Install

$ agentstack add skill-simiancraft-simiancraft-skills-mobile-accessibility

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No 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.

Are you the author of Mobile Accessibility? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.