iOS Accessibility Agent Skill
An iOS accessibility skill: VoiceOver, Dynamic Type, Voice Control, Switch Control and manual testing in UIKit and SwiftUI
- 177 ★ on the repository
- Last commit
- MIT
Minimal access
Why this level
- The skill is text references that run nothing themselves; the agent edits labels and screen layouts in your project following them.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/ios-accessibility-agent-skillDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skill is text references that run nothing themselves; the agent edits labels and screen layouts in your project following them.
This is third-party code. Review the repository files before installing.
What it does
iOS Accessibility Agent Skill guides the agent through accessibility of iPhone and iPad apps. Before advising, the skill finds out what the project is written in (UIKit, SwiftUI or a mix) and the minimum iOS version, because some APIs exist only on newer systems. The agent gives solutions in descending order of confidence with the pros and cons of each. References are split by topic: VoiceOver and Dynamic Type separately for UIKit and SwiftUI, Voice Control, Switch Control, Full Keyboard Access, manual and automated testing, general practices and a glossary. The skill collects anti-patterns: the word «button» in a button's label, fixed font sizes, hardcoded text colors, hiding interactive elements from VoiceOver, relying on a lone `onTapGesture`. Norms such as a touch target of at least 44×44 points sit alongside.
Who it is for. iOS developers on UIKit and SwiftUI who are bringing an app up to working with VoiceOver, Dynamic Type and Switch Control.
Good fit when
- VoiceOver says «button» twice on a button because the trait word was written into the label, and the agent rewrites the labels.
- Text does not grow when the font size is increased, and the agent swaps fixed sizes for text styles.
- Before a release a manual test plan covering VoiceOver, Voice Control and Full Keyboard Access is prepared alongside automated tests.
- The app has a shared design system, and the improvement goes into the component so it reaches every screen.
Not a fit when
- The app is web, Android or desktop: the skill covers only iOS.
- You need a legal opinion or a compliance certificate: the skill does not replace an audit or testing with real users.
- The question is about SwiftUI in general, without accessibility: skills about the framework itself fit better.
Example request
Use the ios-accessibility skill and review the current screen for VoiceOver support: labels, traits, focus order.Limitations
The author calls the skill work in progress and not exhaustively tested, so the agent's solutions need checking on a device with VoiceOver. Accessibility problems rarely have one correct fix, so the final call stays with the developer. Some APIs need a recent iOS, for example `AccessibilityFocusState` and `.accessibilityRotor` from iOS 15 and `.accessibilityRepresentation` from iOS 16, so advice changes on older deployment targets. The repository's last commit is dated March 2026.
How to disable. Remove the skill with the same CLI you installed it with or delete the `ios-accessibility` directory from the agent's skills directory by hand.
FAQ
How do I call the skill on a specific screen?
Name it in the request: «Use the ios-accessibility skill and review the current screen for VoiceOver support». The agent asks about UIKit or SwiftUI and the iOS version if the project does not show it.
Are automated checks enough?
No. The skill states that automation is limited to Accessibility Inspector and UI tests and manual testing with VoiceOver is essential. The agent gives it next to every code change.
Which related accessibility skills does the author mention?
The README points to Pasquale Vittoriosi's swift-accessibility-skill, released earlier, as a complement with stronger coverage of some topics. The skills were developed in parallel.
What does the skill say about a button's label?
The label names the action, such as «Close»; VoiceOver adds the word «button» itself when the element has the button trait.
What does the skill advise for navigation bars and tab bars at large font sizes?
Navigation bar, toolbar and tab bar items are not scaled with Dynamic Type. The skill recommends Large Content Viewer, available from iOS 13 for them.
Discussion
No questions or reviews yet.
Related
SkillsSkills for Apple development: SwiftUI, UIKit and Liquid Glass references, Swift 6 guides and a router for iOS 26+ tasks
A skill that gives the agent Apple's own SwiftUI guidance, which the installer extracts from your local Xcode
A skill with scripts for building iOS apps and driving the simulator through the accessibility tree, with compact output for agents
Skills exported from Xcode guide agents through SwiftUI reviews, test modernization and Apple platform security checks
Six skills on iOS app speed: launch time, profiling, SwiftUI, Swift Concurrency, runtime costs and perceived performance.
Two SwiftUI skills: native Liquid Glass for iOS 26 and adaptive layout for the foldable iPhone Duo with no separate app version
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| iOS Accessibility Agent Skill (this card) | no | 177 | |
| Accessibility Agents | no | 445 | WCAG 2.2 AA requirements as skills for Claude Code and Copilot; this covers iOS specifics: VoiceOver, Dynamic Type, UIKit and SwiftUI |
| SwiftUI Pro | no | 6,532 | a general SwiftUI code review; this covers only accessibility across two frameworks |
README in short
The README opens with two caveats: the skill is a work in progress, and accessibility is not deterministic and needs real testing. Next come installation through skills.sh or by hand, links to the skills directories in Codex, Claude Code and Cursor, the scope and a request for feedback with the prompt and a sample of output.
README badge
Original SKILL.md
--- name: ios-accessibility description: 'Expert guidance on iOS accessibility best practices, patterns, and implementation. Use when developers mention: (1) iOS accessibility, VoiceOver, Dynamic Type, or assistive technologies, (2) accessibility labels, traits, hints, or values, (3) automated accessibility testing, auditing, or manual testing, (4) Switch Control, Voice Control, or Full Keyboard Access, (5) inclusive design or accessibility culture, (6) making apps work for users with disabilities.' --- # iOS Accessibility ## Overview This skill provides expert guidance on iOS accessibility, covering VoiceOver, Dynamic Type, assistive technologies, inclusive design practices, and both UIKit and SwiftUI implementations. Use this skill to help developers build apps that work for everyone. ## The Approach - **Shift-left** — Accessibility is part of the process. It needs to be considered even in prototypes or MVPs. - **User-centric** — Accessibility is about people. Checklists help, but the goal is not checklist compliance. The goal is to offer a great experience for users with disabilities. - **Progress over perfection** — Anytime is a good time to start. Focus on iterative and incremental improvements as you go. It goes a long way. - **Test as you go** — Manual testing is part of development. ## Agent Behavior Contract 1. **Accessibility is non-deterministic.** Propose potential solutions in order of confidence and present with clear pros, cons, and trade-offs. 2. Before proposing fixes, identify the platform (UIKit vs SwiftUI) and the assistive technology, accessibility feature, or design consideration in context. 3. Do not recommend accessibility fixes without considering the user experience impact. 4. Prefer manual testing guidance alongside code changes, together with any automated or semi-automated solutions. 5. Cross-reference multiple assistive technologies when relevant (VoiceOver, Voice Control, Switch Control, Full Keyboard Access). ### Anti-Patterns to Avoid - **Do not add trait names to labels** — Say "Close", not "Close button" (VoiceOver adds "button" automatically, when using the button trait) - **Do not use `.accessibilityHidden(true)` on interactive elements** — Users won't be able to access them - **Do not use fixed font sizes** — Always use text styles for Dynamic Type support - **Do not use hardcoded colors for text** — Use semantic colors (`.label`, `.secondaryLabel`) for contrast and Dark Mode - **Do not group UIKit elements without a clear combined label** — If `isAccessibilityElement = true`, set `accessibilityLabel` (and value/traits as needed). - **Do not group SwiftUI elements without a clear combined label** — If `.accessibilityElement(children: .ignore)` is used, provide label/value/traits manually. - **Do not add hints unless needed** — It should be clear what a component expresses, and does, by its label/value/traits. Only configure for adding extra clarity or context. - **Do not rely on `onTapGesture` alone** — Prefer semantic controls like `Button`. If gesture handling is unavoidable, add button traits and clear labels. - **Do not scale chrome controls with Dynamic Type** — For navigation bars, toolbars, and tab bars, prefer Large Content Viewer (iOS 13+) using [`.accessibilityShowsLargeContentViewer`](https://developer.apple.com/documentation/swiftui/view/accessibilityshowslargecontentviewer(content:)) / [`UILargeContentViewerItem`](https://developer.apple.com/documentation/uikit/uilargecontentvieweritem). ### General Guidance **Prefer native components:** Whenever possible, use Apple's native components and customize them to your needs instead of building custom components from scratch. **Design system first:** Whenever the project uses a design system of its own (colors, text styles, component catalog), propose changes in the design system itself so the improvement snowballs everywhere in the app using an improved component. **Platform parity:** The same accessibility principles apply to both UIKit and SwiftUI, but APIs and implementation details differ. ## Project Settings Intake (Evaluate Before Advising) Before providing accessibility guidance, determine: