agentsclimarketplace
Sign in

Mobile accessibility

Skill simiancraft/simiancraft-skills/skills/mobile-accessibility

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.From its SKILL.md

Install
npx -y skills add simiancraft/simiancraft-skills --skill mobile-accessibility

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

SKILL.md

3.7 KB, 624 tokens by cl100k_base, 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 propWho reads itWhat it is for
accessibilityIdentifiertestIDthe drivera stable handle to find an element in a script
accessibilityLabelaccessibilityLabelthe human (VoiceOver) and the auditorthe 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.

What ships with it: 3 files

11.4 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most accessibility skills give in 624 tokens

Counted across 360 of the 378 authors here whose files we hold, read 2026-09-06

  • Respect prefers-reduced-motionin 49 of 360, across 41 files
  • Add alt text to every imagein 47 of 360, across 40 files
  • Make every interactive element keyboard operablein 46 of 360, across 37 files
  • Keep focus indicators visiblein 42 of 360, across 37 files
  • Associate every form input with a labelin 42 of 360, across 35 files
  • Ensure 4.5:1 contrast for normal textin 38 of 360, across 32 files
  • Trap focus in modals and restore it on closein 37 of 360, across 25 files
  • Prefer native HTML elements over ARIAin 37 of 360, across 33 files
  • Add aria-label to icon-only buttonsin 24 of 360, across 13 files
  • Announce dynamic content updates with aria-livein 24 of 360, across 16 files
  • Use ARIA only when native HTML is insufficientin 23 of 360, across 15 files
  • Meet WCAG AA contrast ratiosin 23 of 360

Said here and by no other author read

  • Prefer the accessibility identifier handle for driving
  • Fall back to tapping by visible label
  • Avoid coordinates
  • Keep identifiers as handles and labels as names
  • Cite a primary source for every claim

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.