Accessibility Testing for iPhone Apps: A Practical Guide

Short answer

Accessibility testing on iOS is three passes in a fixed order. First, an automated audit with Accessibility Inspector to catch missing labels, low contrast, and small touch targets. Second, a VoiceOver-only walkthrough of every core flow, held against Apple’s accessibility chapter of the Human Interface Guidelines. Third, every screen at the largest Dynamic Type sizes. The order matters because each pass gets cheaper when the previous one is clean.

Start with the automated audit

Xcode ships with Accessibility Inspector, a tool that points at a running app in the Simulator or on a device and flags issues screen by screen. Since Xcode 15 you can run a full audit from the inspector with one click, and assert the same audits inside UI tests, which Apple demonstrated in a WWDC session on accessibility audits.

The audit catches the mechanical failures:

• Elements with no accessibility label, so VoiceOver reads “button” and nothing else
• Contrast ratios below the WCAG thresholds
• Touch targets smaller than 44 by 44 points
• Text that does not scale with Dynamic Type
• Images missing descriptions where they carry meaning

Run it on every screen, export the findings, and fix labels first. A missing label makes the element useless to a VoiceOver user, and the fix is usually a single modifier in SwiftUI or one field in Interface Builder. On UIKit screens the same properties live on UIAccessibility, which every UIView adopts.

Automated audits are necessary but not sufficient. They check properties, not experience. An app can pass every audit and still be unusable with a screen reader because the reading order jumps around, a custom gesture has no accessible alternative, or the labels are technically present but say nothing useful.

Walk the app with VoiceOver only

The manual walkthrough is the test that matters most. Turn on VoiceOver (triple-click the side button once you have set the accessibility shortcut), enable Screen Curtain so the display goes black, and complete your app’s core flow end to end: sign up, do the main task, pay if there is a payment. If you cannot finish the flow without looking, neither can a blind customer.

What to listen for:

• Reading order. VoiceOver should move through the screen the way a sighted user scans it: title, primary content, actions. Custom layouts often produce a scrambled order, and the fix is grouping child elements or setting an explicit sort priority.
• Labels that say what things do. “Favorite, button” beats “heart-icon-filled, button”. Decorative images should be hidden from the accessibility tree entirely so they never waste a swipe.
• State announcements. Toggles, tabs, and selected cells must announce their state, not just their name. A tab that does not say “selected” strands the user.
• Escape hatches. Every modal needs a way out that VoiceOver can find, and the two-finger scrub gesture should dismiss it.
• Live updates. Loading spinners, toasts, and validation errors need announcements; a silent error message is invisible.
• The rotor. Twist two fingers to open it and check that headings navigation actually works. If your section titles are plain text instead of carrying the header trait, the rotor’s fastest navigation mode is dead on your screen, and long pages become a swipe marathon.

Apple’s VoiceOver page in the Human Interface Guidelines is specific about labels, traits, and grouping, and we treat it as the acceptance spec when reviewing client screens. Keep a printed copy of its checklist next to the test device; reviewers move faster with the reference in hand than from memory.

The audience is bigger than most founders expect. WebAIM’s screen reader survey reports that most screen reader users work on mobile, and Apple’s own accessibility overview describes the assistive features shipped on every device by default. Treat VoiceOver users as a real segment, not a compliance checkbox.

Stress the layout with Dynamic Type

Set the text size to the largest accessibility size (Settings, Accessibility, Display and Text Size, Larger Text, then drag the slider to the top) and open every screen again. This single check finds more visual bugs than any other:

• Labels truncating with an ellipsis where the full text matters
• Fixed-height rows clipping two-line text
• Buttons whose text overflows the tap target
• Horizontal stacks that need to reflow vertically at large sizes
• Toolbars and tab bars where labels collide

In SwiftUI, most of these are solved by trusting the system text styles and letting stacks reflow; Apple’s typography guidance documents how each style scales across the size categories. Custom fonts scale too if you register them with the text style system instead of hardcoding point sizes. If a screen cannot survive the largest size, the answer is reflow, never capping the user’s chosen size.

There are twelve size categories in total, seven standard and five accessibility sizes, and the jump from the default to the top is roughly a doubling of body text. Test at three points: the default, the largest standard size, and the largest accessibility size. A layout that survives all three almost always survives everything between them.

Test the settings people actually change

VoiceOver and Dynamic Type are the big two, but the Settings app exposes a row of switches that real customers flip every day, and each one can break an app in a distinct way. Apple lists them all in its iPhone accessibility support documentation.

Setting	What breaks	What to verify
Reduce Motion	Parallax and spring animations still play	Animations swap to crossfades
Reduce Transparency	Blur-dependent text loses contrast	Backgrounds become opaque
Bold Text	Custom fonts ignore the toggle	Weights step up across screens
Increase Contrast	Subtle borders vanish or stay faint	Separators and buttons stay visible
Smart Invert	Photos and logos invert to negatives	Images are marked to opt out
Voice Control	Unlabeled controls cannot be addressed	Every control has a speakable name

Ten minutes per setting is enough. The wins are cheap: marking images for Smart Invert or swapping an animation for a crossfade is typically one line each.

The five checks that catch most failures

Check	Tool	Typical failure	Typical fix
Labels and traits	Accessibility Inspector	Unlabeled icon buttons	accessibilityLabel on the control
Reading order	VoiceOver walkthrough	Scrambled custom layout	Group elements, set sort priority
Contrast	Inspector audit	Gray text on white	Darken to meet 4.5:1
Dynamic Type	Largest text size	Clipped or truncated text	Scalable fonts, flexible rows
Touch targets	Inspector audit	28pt icon buttons	Pad to 44 by 44 points

Contrast thresholds come from WCAG 2.2: 4.5:1 for body text and 3:1 for large text. WCAG formally targets the web, but iOS teams borrow the numbers because they are measurable and defensible, and European accessibility rules reference them. When a brand color fails the ratio against white, darkening the color by one shade almost always passes without the designer noticing the change.

Make it stick in CI

One pass before launch decays quickly. Every release adds screens, and screens added under deadline are exactly the ones that ship unlabeled. Two habits keep an app accessible release after release:

1. Automated audits in UI tests. XCUITest can call performAccessibilityAudit on each screen your tests already visit. A new unlabeled button fails the build instead of shipping. The audit accepts specific types (element descriptions, contrast, Dynamic Type, hit regions, traits), so start with element descriptions and Dynamic Type, then widen as the suite stabilizes. Known false positives can be filtered in the audit’s issue handler rather than by turning the whole check off.
2. A VoiceOver smoke test per release. Ten minutes on the core flow before each submission, with Screen Curtain on. Put it in the release checklist next to screenshots and release notes, and rotate who runs it so the whole team internalizes what the app sounds like.

On client projects we also tag every accessibility fix in the tracker, because the pattern of what keeps breaking tells you where the design system needs a stronger default. If your icon buttons keep shipping without labels, the fix is a button component that requires a label parameter, not another round of QA.

When a full audit is overkill

An internal tool used by five people on a desk does not need the same rigor as a consumer app, and a prototype you will throw away next month needs almost none. Spending the full day makes sense once real customers depend on the app, and it becomes non-negotiable for apps in banking, health, education, government, or anything sold in the EU. That last category is now a legal matter, not a preference: the European Accessibility Act applies to products and services placed on the EU market since June 28, 2025, and consumer-facing apps in areas like e-commerce and banking fall squarely under it. Scale the routine to the stakes: the automated audit is cheap enough to run on everything, while the deep manual passes earn their time on products with a public audience.

Most teams stop after the automated audit because it produces a satisfying list. The audit finds the missing label; only the walkthrough finds that your checkout reads the total before the line items, or that the map screen traps focus. Budget the afternoon for the manual pass. That half day separates apps that technically pass from apps that blind users recommend to each other. It is the same standard we hold our own client work to, and you can see what that looks like in practice in our work.