ios-accessibility

iOS Accessibility

Production-grade accessibility skill for iOS codebases aligned with WCAG 2.2 AA and Apple Human Interface Guidelines. Operates correction-first — AI coding assistants (including Claude) systematically generate inaccessible iOS code because most training data lacks accessibility. This skill intercepts those patterns and enforces accessible output from the start.

The skill covers both SwiftUI and UIKit with framework-appropriate patterns, and produces code that works across VoiceOver, Switch Control, Voice Control, Full Keyboard Access, and Dynamic Type.

Why This Skill Exists

Research (CodeA11y, arXiv 2502.10884) found that AI omits accessibility because: (1) developers don't prompt for it so AI doesn't provide it, (2) most training code is inaccessible, and (3) generated code omits manual steps like replacing placeholder labels. This skill ensures every code generation pass includes accessibility from the start — not as an afterthought.

Quick Decision Trees

Which framework's patterns apply?

Is the file SwiftUI (.swift with View conformance)?
├── YES → Apply SwiftUI patterns → Read references/swiftui-patterns.md
└── NO  → Is the file UIKit (.swift with UIView/UIViewController)?
    ├── YES → Apply UIKit patterns → Read references/uikit-patterns.md
    └── NO  → Mixed — apply BOTH checklists per file type

Is this element interactive?

Can the user tap/activate this element?
├── YES → Is it using Button, Toggle, Slider, Picker, or Link?
│   ├── YES → Standard control — verify accessibilityLabel exists
│   └── NO  → Using onTapGesture or custom view?
│       └── 🔴 REPLACE with Button or appropriate standard control
│           onTapGesture is invisible to VoiceOver, Switch Control, and eye tracking
└── NO  → Is it a meaningful image or icon?
    ├── YES → Add accessibilityLabel describing content, not appearance
    └── NO  → Decorative → Image(decorative:) or .accessibilityHidden(true)

Does this text support Dynamic Type?