iOS App Accessibility Checklist: 12 Essentials Every Designer Should Verify

At Iris, we audit dozens of iOS apps every year, and the same accessibility gaps keep showing up. Missing VoiceOver labels, hard-coded font sizes, 3:1 contrast on primary CTAs, buttons the size of a raisin. The good news: most of these issues take minutes to fix once you know what to look for.

This iOS app accessibility checklist is the exact list our designers and iOS engineers run through before shipping. It’s opinionated, practical, and packed with SwiftUI snippets and the real mistakes we spot in client audits.

Why bother with an iOS accessibility audit in 2026?

Since the European Accessibility Act came into force in June 2025, any consumer-facing app sold in the EU has to meet WCAG-aligned criteria. Apple has also tightened App Store review for accessibility misrepresentation, and the new Accessibility Nutrition Labels introduced in iOS 18 mean users can now see, before downloading, whether your app supports VoiceOver, Dynamic Type, sufficient contrast, and more.

Translation: accessibility is now a discoverability feature, not just an ethical one.

The 12-point iOS app accessibility checklist

#	Item	Where to test
1	VoiceOver labels on every interactive element	Settings > Accessibility > VoiceOver
2	Meaningful reading order	VoiceOver swipe navigation
3	Dynamic Type support up to AX5	Control Center text size slider
4	Color contrast (4.5:1 text, 3:1 UI)	Xcode Accessibility Inspector
5	Touch targets at least 44×44 pt	Manual review + Inspector
6	Reduce Motion respected	Settings > Accessibility > Motion
7	Increase Contrast & Differentiate Without Color	Accessibility settings
8	Haptic and audio alternatives	Silent mode test
9	Focus management on modals and alerts	VoiceOver + Full Keyboard Access
10	Form accessibility (labels, errors, hints)	VoiceOver walkthrough
11	Video captions and audio descriptions	Media playback screens
12	Accessibility Nutrition Label accuracy	App Store Connect

1. VoiceOver labels on every interactive element

The most common issue we find? Icon-only buttons with no label. VoiceOver reads them as “button” and nothing else.

Button {
    viewModel.toggleFavorite()
} label: {
    Image(systemName: "heart.fill")
}
.accessibilityLabel("Add to favorites")
.accessibilityHint("Double tap to save this article")

Common mistake: using the SF Symbol name as the label (“heart fill”). Always write the label from the user’s perspective, describing the action, not the visual.

2. Reading order and grouping

SwiftUI usually gets reading order right, but as soon as you introduce ZStack or overlays, VoiceOver starts jumping around. Group related content:

HStack {
    Image("avatar")
    VStack(alignment: .leading) {
        Text("Sarah Chen")
        Text("Product Designer")
    }
}
.accessibilityElement(children: .combine)

3. Dynamic Type: the item that breaks the most layouts

Roughly one iOS user in three uses a non-default text size. Yet in almost every audit we run, we find at least one screen that clips, truncates, or overlaps at AX3+.

• Use text styles (.font(.body), .headline) instead of fixed point sizes.
• Wrap horizontal layouts that hold text in ViewThatFits to gracefully switch to vertical stacks.
• Test at AX5, not just the default.

ViewThatFits(in: .horizontal) {
    HStack { label; value }
    VStack(alignment: .leading) { label; value }
}

4. Color contrast

The rule from WCAG 2.2:

• 4.5:1 for body text
• 3:1 for large text (18pt bold or 24pt regular and above) and UI components

Gray placeholder text on white is the offender we flag most often. Also watch for brand colors used on colored backgrounds. Open Xcode’s Accessibility Inspector > Color Contrast Calculator and check every state, including disabled and pressed.

5. Touch targets: 44×44 pt minimum

Apple’s HIG has been clear on this since forever, and it’s still ignored. If a tap area is smaller than 44 points, wrap it:

Button(action: dismiss) {
    Image(systemName: "xmark")
}
.frame(minWidth: 44, minHeight: 44)
.contentShape(Rectangle())

Targets should also not overlap. Deque’s mobile guidance recommends spacing between compact targets so a user with reduced motor control doesn’t tap the wrong one.

6. Reduce Motion

Parallax, spring bounces, and page transitions can trigger vestibular issues. Respect the user’s preference:

@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? nil : .spring(), value: state)
}

7. Don’t rely on color alone

Red for error, green for success is a classic anti-pattern. Add an icon, a label, or a pattern. Test with the Differentiate Without Color toggle enabled.

8. Alternatives for haptics and audio

If a critical event only vibrates, deaf-blind users miss it. If it only plays a sound, silent-mode users miss it. Pair every non-visual signal with a visual state change.

9. Focus management

When a sheet or alert appears, VoiceOver focus should move to it, not stay on the trigger button. Use @AccessibilityFocusState:

@AccessibilityFocusState private var isAlertFocused: Bool

.alert("Delete account?", isPresented: $showAlert) {
    // buttons
}
.onChange(of: showAlert) { _, new in
    if new { isAlertFocused = true }
}

10. Forms: labels, hints, errors

• Every field must have a visible label AND an accessibility label matching it.
• Error messages should be announced via AccessibilityNotification.Announcement.
• Group the field, its label, and its error so VoiceOver reads them together.

11. Media accessibility

Videos need closed captions, and educational or narrative content needs audio descriptions. If you use AVPlayer, ship a WebVTT track and let iOS surface it automatically.

12. Accessibility Nutrition Labels

Since iOS 18, App Store Connect asks you to declare which accessibility features your app supports. Lying here is a fast track to rejection and bad reviews. Only tick VoiceOver, Dynamic Type, Sufficient Contrast, Voice Control, etc. after you’ve verified them on device.

How we run an accessibility audit at Iris

1. Automated pass with Xcode Accessibility Inspector on every screen.
2. Manual VoiceOver run completing the top 5 user journeys with the screen curtain on.
3. Dynamic Type sweep at AX3 and AX5.
4. Contrast audit in Figma and again on device (colors shift on OLED).
5. User testing with at least one person who relies on assistive tech daily.

Common mistakes we see in client audits

• Custom controls built with onTapGesture that VoiceOver treats as plain text.
• Splash screens that autoplay animations regardless of Reduce Motion.
• Bottom sheets that trap VoiceOver focus behind them.
• Numeric inputs without keyboardType(.decimalPad), forcing switch control users through a full keyboard.
• Onboarding illustrations marked as buttons because someone added a tap gesture on the whole VStack.

FAQ

What’s the fastest way to test my iOS app for accessibility?

Enable VoiceOver via the Accessibility Shortcut (triple-click the side button), then complete your app’s core flow with your eyes closed. You’ll find 80% of issues in ten minutes.

Is SwiftUI more accessible than UIKit by default?

SwiftUI gives you sensible defaults, especially for labels, traits, and grouping. But it can hide accessibility issues in complex layouts. UIKit gives more control. Neither is automatically compliant.

Do I need to support every accessibility feature on iOS?

Not every one, but you should support the core set: VoiceOver, Dynamic Type, sufficient contrast, reduced motion, and adequate touch targets. These cover the majority of assistive-tech users and are what the Accessibility Nutrition Label surfaces to buyers.

How does the European Accessibility Act affect my app?

If you sell to consumers in the EU, your app must meet WCAG 2.1 AA equivalent criteria on mobile. Enforcement is now active and fines vary by member state. Treat WCAG plus Apple’s HIG accessibility section as your baseline.

Which tools do you use at Iris for iOS accessibility audits?

Xcode Accessibility Inspector, the Environment Overrides pane in Xcode, Stark for Figma, and real devices with VoiceOver, Voice Control, and Switch Control. Automated tools catch structural issues, but nothing replaces manual testing.

---

Need a full accessibility audit of your iOS app? Our design studio runs fixed-scope audits with a prioritized fix list and Swift/SwiftUI code recommendations. Get in touch with Iris.