SwiftUI WCAG Accessibility Auditor
Overview
Audit SwiftUI iOS features with a dual mode:
- WCAG-driven coverage and evidence (
what fails / what is uncertain / why)
- SwiftUI patch-ready remediation (
what to change with minimal code edits)
Treat this as a code audit. Do not run the app. If a result cannot be proven from source, mark it as Needs user verification and add a concrete user follow-up check.
When to Use This Skill vs Nearby Skills
Use this merged skill when you need both:
- WCAG 2.2 mapping / traceability, and
- SwiftUI-specific fixes/snippets
Prefer the other skills when:
mobile-accessibility-audit: feature may include UIKit or you only need standards-first audit coverage
swiftui-accessibility-auditor: you want a fast SwiftUI-only heuristic review without WCAG traceability
Load Order
- Read
references/ios-audit-workflow.md for code-only audit process, statuses, evidence rules, and baseline report format.
- Read
references/ios-audit-checklist.md for WCAG SC coverage priorities and code signals.
- Read
references/wcag2mobile-ios-reference.md when interpreting mobile-specific applicability or draft maturity of a criterion.
- Read
references/ios-accessibility-api-examples.md, starting with the SwiftUI sections only.
- Read
references/swiftui-remediation-guide.md for patch strategy, non-goals, priority model, and SwiftUI fix patterns.
- Use
references/swiftui-manual-checklist.md only when generating user follow-up checks or a final manual validation list.
Scope Rules
- Audit native iOS SwiftUI code only.
- Audit
UIViewRepresentable / UIViewControllerRepresentable bridges only to the extent they affect the SwiftUI feature.
- If the feature delegates core behavior to UIKit, say so and either narrow the audit or recommend using
mobile-accessibility-audit.
- Do not broaden scope to macOS, watchOS, web, or non-SwiftUI implementations.
Audit Execution (Merged Workflow)
- Define the scoped feature flow and in-scope screens/states.
- Identify the SwiftUI entry views and related subviews for the feature.
- Run the WCAG checklist (
ios-audit-checklist.md) and record evidence with statuses.
- Use the SwiftUI API examples to avoid false positives and identify missing semantics.
- Generate patch-ready fix suggestions using
swiftui-remediation-guide.md.
- Produce a Markdown report with:
- prioritized findings (
P0, P1, P2)
- WCAG SC mapping for each finding
- patch-ready snippet embedded in each finding
- user follow-up checks (only for code-indeterminate items)
Output Format (Strict, Concise)
Be concise. Use the following structure exactly.
Rules:
- Group findings by priority using top-level headings:
# Findings - P0, # Findings - P1, # Findings - P2
- Omit empty priority groups.
- Put the code snippet in the same finding section (not in a separate snippets section).
- Omit the WCAG coverage matrix unless the user explicitly asks for it.
- Add
# Scope / Assumptions only if ambiguity materially affects the audit.
- Add
# User Follow-Up Checks only if there are Needs user verification items.
Template for each finding:
# Findings - P1
## 1. <Problem name>
- **What**: <problem description with code evidence>
- **Where**: <file path + line(s)>
- **Fix suggestion**: <suggested fix in words>
- **WCAG**: <SC # - Title (Level)>
```swift
// patch-ready snippet
```
Notes:
- Include
Confidence inside *What* when useful (for example: Likely issue (confidence: medium)).
- Keep snippets minimal and directly applicable to the cited code path.
- If no code snippet is appropriate, state why in
*Fix suggestion* (rare).
Practical Search Guidance (SwiftUI-first)
Start in the feature path and prefer SwiftUI symbols first:
rg --files | rg '\\.(swift)$'
rg -n "struct .*View: View|body: some View|NavigationStack|sheet\\(|fullScreenCover\\(" .
rg -n "accessibility(Label|Hint|Value|Hidden)|accessibility(AddTraits|RemoveTraits)|accessibilityElement\\(|accessibilityFocused\\(" .
rg -n "@AccessibilityFocusState|onTapGesture|DragGesture|lineLimit\\(|minimumScaleFactor|dynamicTypeSize" .
Then consult references/ios-accessibility-api-examples.md for pattern interpretation.
Example Requests
Use $swiftui-wcag-accessibility-auditor to audit this SwiftUI checkout feature against WCAG 2.2 and return prioritized findings with patch-ready fixes in the strict finding format.
Use $swiftui-wcag-accessibility-auditor to review this SwiftUI login + OTP flow for accessible authentication (3.3.8) and suggest minimal code changes.
Use $swiftui-wcag-accessibility-auditor to audit this settings screen and produce user follow-up checks only for contrast, target size, and VoiceOver announcement timing.
Resources
references/ios-audit-workflow.md: code-only audit process, statuses, evidence quality rules, and report structure.
references/ios-audit-checklist.md: iOS WCAG checklist and SC coverage priorities.
references/wcag2mobile-ios-reference.md: cleaned mobile interpretation reference (WCAG2Mobile/WCAG2ICT distilled for iOS audits).
references/ios-accessibility-api-examples.md: SwiftUI + UIKit API examples (use SwiftUI sections first in this skill).
references/swiftui-remediation-guide.md: SwiftUI patch strategy, non-goals, priorities, and fix patterns.
references/swiftui-manual-checklist.md: compact user manual validation checklist for follow-up checks.
1---2name: swiftui-wcag-accessibility-auditor3description: Audit SwiftUI iOS feature code for accessibility against WCAG 2.2 Level A/AA and return patch-ready fixes. Use when reviewing SwiftUI views/screens (including auth, forms, settings, and custom controls) and you need both standards traceability (WCAG + WCAG2Mobile interpretation) and practical, minimal code changes in a concise priority-grouped Markdown format with user follow-up checks for code-indeterminate behavior.4---5
6# SwiftUI WCAG Accessibility Auditor
7
8## Overview
9
10Audit SwiftUI iOS features with a dual mode:
11
12- WCAG-driven coverage and evidence (`what fails / what is uncertain / why`)
13- SwiftUI patch-ready remediation (`what to change with minimal code edits`)
14
15Treat this as a code audit. Do not run the app. If a result cannot be proven from source, mark it as `Needs user verification` and add a concrete user follow-up check.
16
17## When to Use This Skill vs Nearby Skills
18
19Use this merged skill when you need both:
20
21- WCAG 2.2 mapping / traceability, and
22- SwiftUI-specific fixes/snippets
23
24Prefer the other skills when:
25
26- `mobile-accessibility-audit`: feature may include `UIKit` or you only need standards-first audit coverage
27- `swiftui-accessibility-auditor`: you want a fast SwiftUI-only heuristic review without WCAG traceability
28
29## Load Order
30
311. Read `references/ios-audit-workflow.md` for code-only audit process, statuses, evidence rules, and baseline report format.
322. Read `references/ios-audit-checklist.md` for WCAG SC coverage priorities and code signals.
333. Read `references/wcag2mobile-ios-reference.md` when interpreting mobile-specific applicability or draft maturity of a criterion.
344. Read `references/ios-accessibility-api-examples.md`, starting with the SwiftUI sections only.
355. Read `references/swiftui-remediation-guide.md` for patch strategy, non-goals, priority model, and SwiftUI fix patterns.
366. Use `references/swiftui-manual-checklist.md` only when generating user follow-up checks or a final manual validation list.
37
38## Scope Rules
39
40- Audit native iOS SwiftUI code only.
41- Audit `UIViewRepresentable` / `UIViewControllerRepresentable` bridges only to the extent they affect the SwiftUI feature.
42- If the feature delegates core behavior to UIKit, say so and either narrow the audit or recommend using `mobile-accessibility-audit`.
43- Do not broaden scope to macOS, watchOS, web, or non-SwiftUI implementations.
44
45## Audit Execution (Merged Workflow)
46
471. Define the scoped feature flow and in-scope screens/states.
482. Identify the SwiftUI entry views and related subviews for the feature.
493. Run the WCAG checklist (`ios-audit-checklist.md`) and record evidence with statuses.
504. Use the SwiftUI API examples to avoid false positives and identify missing semantics.
515. Generate patch-ready fix suggestions using `swiftui-remediation-guide.md`.
526. Produce a Markdown report with:
53 - prioritized findings (`P0`, `P1`, `P2`)
54 - WCAG SC mapping for each finding
55 - patch-ready snippet embedded in each finding
56 - user follow-up checks (only for code-indeterminate items)
57
58## Output Format (Strict, Concise)
59
60Be concise. Use the following structure exactly.
61
62Rules:
63
64- Group findings by priority using top-level headings: `# Findings - P0`, `# Findings - P1`, `# Findings - P2`
65- Omit empty priority groups.
66- Put the code snippet in the same finding section (not in a separate snippets section).
67- Omit the WCAG coverage matrix unless the user explicitly asks for it.
68- Add `# Scope / Assumptions` only if ambiguity materially affects the audit.
69- Add `# User Follow-Up Checks` only if there are `Needs user verification` items.
70
71Template for each finding:
72
73````md
74# Findings - P1
75
76## 1. <Problem name>
77- **What**: <problem description with code evidence>
78- **Where**: <file path + line(s)>
79- **Fix suggestion**: <suggested fix in words>
80- **WCAG**: <SC # - Title (Level)>
81
82```swift
83// patch-ready snippet
84```
85````
86
87Notes:
88
89- Include `Confidence` inside `*What*` when useful (for example: `Likely issue (confidence: medium)`).
90- Keep snippets minimal and directly applicable to the cited code path.
91- If no code snippet is appropriate, state why in `*Fix suggestion*` (rare).
92
93## Practical Search Guidance (SwiftUI-first)
94
95Start in the feature path and prefer SwiftUI symbols first:
96
97```bash
98rg --files | rg '\\.(swift)$'
99rg -n "struct .*View: View|body: some View|NavigationStack|sheet\\(|fullScreenCover\\(" .
100rg -n "accessibility(Label|Hint|Value|Hidden)|accessibility(AddTraits|RemoveTraits)|accessibilityElement\\(|accessibilityFocused\\(" .
101rg -n "@AccessibilityFocusState|onTapGesture|DragGesture|lineLimit\\(|minimumScaleFactor|dynamicTypeSize" .
102```
103
104Then consult `references/ios-accessibility-api-examples.md` for pattern interpretation.
105
106## Example Requests
107
108- `Use $swiftui-wcag-accessibility-auditor to audit this SwiftUI checkout feature against WCAG 2.2 and return prioritized findings with patch-ready fixes in the strict finding format.`
109- `Use $swiftui-wcag-accessibility-auditor to review this SwiftUI login + OTP flow for accessible authentication (3.3.8) and suggest minimal code changes.`
110- `Use $swiftui-wcag-accessibility-auditor to audit this settings screen and produce user follow-up checks only for contrast, target size, and VoiceOver announcement timing.`
111
112## Resources
113
114- `references/ios-audit-workflow.md`: code-only audit process, statuses, evidence quality rules, and report structure.
115- `references/ios-audit-checklist.md`: iOS WCAG checklist and SC coverage priorities.
116- `references/wcag2mobile-ios-reference.md`: cleaned mobile interpretation reference (WCAG2Mobile/WCAG2ICT distilled for iOS audits).
117- `references/ios-accessibility-api-examples.md`: SwiftUI + UIKit API examples (use SwiftUI sections first in this skill).
118- `references/swiftui-remediation-guide.md`: SwiftUI patch strategy, non-goals, priorities, and fix patterns.
119- `references/swiftui-manual-checklist.md`: compact user manual validation checklist for follow-up checks.