Accessibility Audit

A repeatable audit workflow that takes an app from "we think it's accessible" to evidence: automated audits in CI, an Inspector pass, manual assistive-tech passes, and an Accessibility Nutrition Label evaluation you can defend. Distilled from Apple's WWDC23 "Perform accessibility audits" (10035), WWDC19 "Accessibility Inspector" (257), WWDC25 "Evaluate your app for Accessibility Nutrition Labels" (224), and the 2026 Tech Talk "Prepare your app for Accessibility Nutrition Labels" (111433).

Why it matters: Accessibility Nutrition Labels on the App Store make your support (or its absence) visible before download.

When This Skill Activates

• User asks for an accessibility audit, review, or compliance check
• User is preparing Accessibility Nutrition Label declarations for App Store Connect
• User asks about performAccessibilityAudit, Accessibility Inspector, or automated a11y testing
• User mentions EU Accessibility Act / accessibility compliance
• Pre-release checks (pairs with release-review)

The Audit Workflow

1. Define common tasks first (WWDC25 224)

List the primary tasks people download the app for, plus the fundamentals: first-launch experience, login, purchase, settings. Every subsequent pass evaluates these tasks, on every device family the app supports.

2. Automated pass, XCUITest audits in CI

try app.performAccessibilityAudit() audits the current view exactly as the Inspector does; the test fails automatically on findings. Full API, audit-type table, issue filtering, and CI patterns: automated-audits.md. Baseline rules:

• Audits cover only what's on screen, write one audit per distinct screen/state.
• continueAfterFailure = true before the audit to surface all issues in one run.
• Filter accepted issues via the issue handler, never by skipping whole audit types.

3. Inspector pass (WWDC19 257)

Xcode → Open Developer Tool → Accessibility Inspector, target the app: