How do you test accessibility: the Accessibility Inspector, automated audits in XCUITest, identifiers versus labels, and manual testing?

Test at three levels. Inspect: Xcode’s Accessibility Inspector (Xcode ▸ Open Developer Tool) points at any element in the simulator or on a connected device and shows its label, value, traits, hint and frame, runs an audit that flags missing labels, small targets, low contrast and clipped text, and can simulate display settings such as larger text. Automate: in a UI test try app.performAccessibilityAudit() runs the same kinds of checks on the current screen and fails the test on an issue, and you can limit it to categories (.contrast, .dynamicType, .hitRegion, .sufficientElementDescription) and handle known exceptions in a closure, as in the check below. Add one audit per key screen to the UI tests you already run (Q449) so regressions fail the build; you can also assert labels and values in tests (button.label). Automation catches the mechanical problems, and manual testing is still required because a tool cannot tell whether a label makes sense.

Be exact about identifiers versus labels. An accessibilityIdentifier is for tests and is not spoken or shown to users, while the accessibilityLabel is what VoiceOver reads, so UI tests can find an element by a stable identifier while assistive technology reads a meaningful, localised label, and the two should not be confused or merged. Test by hand on a device with VoiceOver on (complete a core task with the screen curtain on), with the largest accessibility text size, Voice Control and Switch Control, Reduce Motion, Increase Contrast, in light and dark and in RTL, with a hardware keyboard, and ideally with people who rely on these tools every day. Record findings with the severity and the user impact, fix them as ordinary bugs, and re-test with the same method. Do not rely on a single audit tool score: green means the common mechanical rules pass, not that the app is usable.