swiftui-wcag-accessibility-auditor

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

1. Read references/ios-audit-workflow.md for code-only audit process, statuses, evidence rules, and baseline report format.
2. Read references/ios-audit-checklist.md for WCAG SC coverage priorities and code signals.
3. Read references/wcag2mobile-ios-reference.md when interpreting mobile-specific applicability or draft maturity of a criterion.
4. Read references/ios-accessibility-api-examples.md, starting with the SwiftUI sections only.
5. Read references/swiftui-remediation-guide.md for patch strategy, non-goals, priority model, and SwiftUI fix patterns.
6. 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)

1. Define the scoped feature flow and in-scope screens/states.
2. Identify the SwiftUI entry views and related subviews for the feature.
3. Run the WCAG checklist (ios-audit-checklist.md) and record evidence with statuses.
4. Use the SwiftUI API examples to avoid false positives and identify missing semantics.
5. Generate patch-ready fix suggestions using swiftui-remediation-guide.md.
6. 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.