ios-accessibility-engineeringlisted

# iOS Accessibility Engineering ## When to invoke - Adding accessibility to a new or changed user-facing View (labels, Dynamic Type, hit targets). - Running a pre-submission accessibility audit against App Store Review guidelines. - User says "make this accessible", "check a11y", "VoiceOver doesn't read this", or "does this pass WCAG". - Reviewing a PR for accessibility regressions. ## VoiceOver: labelling and semantics **Labels, values, and hints** are three distinct channels: - `.accessibilityLabel("Done")` — the noun identifying the element. Keep it short; VoiceOver reads it first. - `.accessibilityValue("3 of 9")` — the current state or quantity. Changes without re-reading the label. - `.accessibilityHint("Double-tap to submit")` — what happens on activation. Users can turn hints off; never put essential info here. In UIKit, set `accessibilityLabel`, `accessibilityValue`, and `accessibilityHint` on any `UIView`. In SwiftUI, use the `.accessibilityLabel(_:)`, `.accessibilityValue(_:)`, and `.accessibilityHint(_:)` modifiers. **Traits** communicate the element's role and state. Common SwiftUI traits: ```swift .accessibilityAddTraits(.isButton) // tappable action .accessibilityAddTraits(.isHeader) // section heading — VoiceOver lets users jump by heading .accessibilityAddTraits(.updatesFrequently) // live score, timer — suppresses constant interruptions .accessibilityAddTraits(.isSelected) // toggle / tab selection state ``` **Grouping** — combine several