Accessibility Inspector for iOS devices

Accessibility issues in an iOS app can be easy to miss during regular functional testing. A button may work when tapped but still be difficult to use with VoiceOver. Text may look fine at the default size but break when a user increases it.

That matters because assistive technology is a normal part of mobile use. In WebAIM’s 2024 Screen Reader User Survey, 70.6% of respondents said an Apple iPhone, iPad, or iPod touch was their primary mobile or tablet platform. The survey also found that 91.3% used a screen reader on a mobile device.

Apple’s Accessibility Inspector helps you catch many of these issues while the app is running. You can inspect labels, traits, values, focus order, contrast, and other properties that affect how users interact with the interface.

By the end, you will understand where Accessibility Inspector is most useful, what it can detect, and where additional testing is still needed.

Why Accessibility Matters in iOS Apps?

Accessibility testing checks whether people can use your app when they rely on features such as VoiceOver, Dynamic Type, Switch Control, or increased contrast. A screen that works correctly with standard touch input can still fail when these settings are enabled.

For iOS teams, accessibility matters for several practical reasons:

• It affects whether core journeys are usable: Login, checkout, search, forms, and navigation must still work when users depend on assistive technologies.
• It exposes UI problems that functional tests may miss: Missing labels, poor focus order, small touch targets, and text that breaks at larger sizes may not affect a standard test run.
• It supports accessibility requirements: Teams may need to meet standards and legal requirements such as WCAG, ADA, Section 508, or the European Accessibility Act, depending on the product and market.
• It improves maintainability: Catching accessibility issues while components are being built is usually easier than fixing the same problems after they appear across multiple screens.

Accessibility should therefore be treated as part of UI quality, not as a separate check performed only before release.

What is an Accessibility Inspector?

The Accessibility Inspector is a tool offered by Apple through Xcode to help developers evaluate and debug their apps’ accessibility. It checks key accessibility properties such as labels, traits, values, hints, and the structure of UI components. This also allows developers to test the app’s compatibility with assistive technologies like VoiceOver and ensure a good user experience.

Testing Accessibility with iOS Accessibility Inspector

Accessibility Inspector is a powerful macOS tool that helps developers test and improve the accessibility of iOS apps. It allows you to handle assistive technologies, inspect accessibility attributes of UI elements, and audit your app for common issues.

Here are some of the key ways to use this tool effectively:

1. Checking User Interface (UI) Elements for Accessibility

Start by checking whether each interactive element exposes enough information for assistive technologies to understand what it is and what it does. A control can look correct on screen but still be unusable if its accessibility metadata is missing or inaccurate.

In the Accessibility Inspector, select elements such as buttons, text fields, images, custom controls, and dynamic content. Then review properties such as:

• Label: Describes the element clearly. For example, a button should expose “Submit” rather than a vague label such as “Button.”
• Value: Communicates the current state of a control, such as whether a switch is on or which option is selected.
• Hint: Adds useful context when the result of an action is not obvious from the label.
• Traits: Tell assistive technologies whether the element behaves like a button, header, image, link, or another control type.

Pay particular attention to custom components. Native UIKit controls often expose accessibility information automatically, while custom views may need explicit configuration.

customView.isAccessibilityElement = true

customView.accessibilityLabel = "Profile image"

customView.accessibilityTraits = .image

Do not stop at checking whether a label exists. Confirm that it is accurate, concise, and still makes sense when the element is encountered without the surrounding visual context.

2. Running an Accessibility Audit

The Accessibility Audit tool scans the app for common accessibility issues like missing labels, low contrast, or misconfigured elements. It automatically identifies the accessibility issues in the running app.

Steps to Implement:

Here are the steps to be followed for performing an accessibility audit:

Step 1: In the Accessibility Inspector, go to the Audit tab.

Step 2: Click Run Audit while your app is running in the simulator.

Step 3: Check for flagged issues like missing accessibility labels, low text/background contrast, etc.

Step 4: Directly fix the issues in Interface Builder:

imageView.accessibilityLabel = "User avatar"

3. Testing Navigation and Interaction

Accessibility is not only about whether individual controls have the right labels. You also need to check whether users can move through the screen in a logical order and operate every important control without relying on standard touch gestures.

Use Accessibility Inspector together with VoiceOver to move through the interface and check:

• Focus order: Elements should be announced in the same logical sequence a user would follow visually.
• Reachability: Buttons, links, form fields, and other controls should receive accessibility focus.
• Grouping: Related content should be grouped correctly so users do not have to navigate through unnecessary individual elements.
• Custom controls: Non-standard components should respond correctly to accessibility focus and actions.
• Dynamic changes: When content appears, disappears, or updates, focus should not jump unexpectedly or leave the user without context.

If the default navigation order does not match the intended experience, you can define the order explicitly:

containerView.accessibilityElements = [label, textField, submitButton]

Test complete user flows rather than a single screen in isolation. A screen can pass element-level checks but still create problems when focus moves between a modal, validation message, menu, or newly loaded content.

4. Verifying System Accessibility Features

Confirm that your app follows all the global accessibility settings, such as bold text, larger fonts, color filters, and reduced motion.

Steps to Implement:

Here are the steps to be followed for verifying system accessibility:

Step 1: In the Simulator, go to Settings > Accessibility and adjust features like:

• Bold Text
• Larger Text/Dynamic Type
• Reduce Motion
• Dark Mode

Step 2: Check how the app behaves:

• Ensure text scales with Dynamic Type (adjustsFontForContentSizeCategory = true)
• Replace animations with fades when Reduce Motion is enabled:

if UIAccessibility.isReduceMotionEnabled {

}

Step 3: Check color contrast in Dark Mode and update colors if needed.

5. Simulating Assistive Technology Uses

Accessibility Inspector helps you evaluate how the interface behaves when users rely on assistive technologies, but the goal is not simply to switch a feature on. You need to check whether the app remains understandable and operable when interaction changes.

For VoiceOver, move through the screen one element at a time and verify:

• Reading order: Content should be announced in a sequence that matches the intended flow.
• Announcements: Labels, values, and state changes should provide enough context without repeating unnecessary information.
• Actions: Buttons, toggles, sliders, and custom controls should respond correctly to VoiceOver gestures.
• Dynamic content: Alerts, validation messages, and updated content should be announced when they affect the current task.

For Switch Control, test whether users can reach and activate every important control without relying on direct touch. Watch for elements that are skipped, grouped incorrectly, or require gestures that cannot be performed through switch navigation.

Also test settings such as Dynamic Type separately. Increase the text size and check whether content remains readable, controls stay usable, and important text is not clipped or hidden.

Limitations of Accessibility Inspector

While the Accessibility Inspector is a powerful and convenient tool during development, it does have several limitations that can impact the accuracy and completeness of accessibility testing. Here are some of them:

1. Platform Dependency

This tool is only available within macOS and requires Xcode, making it inaccessible for teams using Windows or Linux-based systems. It also cannot be used in cross-platform automated pipelines without a macOS infrastructure.

2. Relies on Simulators

Accessibility Inspector is often used with the iOS Simulator because it makes inspection and debugging quick. The limitation is that a simulator cannot reproduce every part of the experience on a physical iPhone or iPad.

Some issues only become clear on real hardware. These can include gesture behavior, focus changes during device rotation, interactions with physical controls, and differences in how assistive technologies behave during longer user flows.

Use the simulator for fast checks during development, but validate important accessibility journeys on real devices before release. This is especially important for flows that depend heavily on VoiceOver, orientation changes, gestures, or device-specific behavior.

3. Cannot Detect Complex Accessibility Issues

Accessibility Inspector can flag many property-level problems, but it may miss issues that only appear when users interact with the app across a full workflow.

For example, a control may have a valid label and trait but still be difficult to use because:

• focus moves to the wrong element after a modal opens
• a validation error appears visually but is not announced
• nested interactive elements create confusing VoiceOver behavior
• a custom control exposes accessibility properties but does not respond correctly to accessibility actions
• dynamic content changes without giving the user enough context

These problems are difficult to detect through inspection alone because the individual elements may look correctly configured.

Use Accessibility Inspector to catch obvious metadata and structure issues, then test complete flows with VoiceOver or Switch Control. This helps uncover interaction problems that only appear when focus, state, and content change over time.

4. Limited Support for Custom Components

Custom user interface elements frequently require manually generated accessibility features. For example, if their accessibility properties are not explicitly set, the Accessibility Inspector may misinterpret or ignore a custom slider, canvas-based controls, or non-standard toggles. This can lead to missing labels, incorrect features, or improper grouping, providing poor user experiences.

How Does Real Device Testing Overcome the Limitations of Accessibility Inspector?

Accessibility Inspector is useful for finding configuration and UI-level issues, but real device testing shows whether those fixes hold up during actual use.

On a physical iPhone or iPad, you can validate behavior that may differ from the simulator, including VoiceOver gestures, focus movement, orientation changes, hardware interactions, and accessibility settings used across complete workflows.

Real device testing is especially useful for checking:

• VoiceOver behavior: Confirm that users can move through screens, activate controls, and understand announcements without unexpected focus changes.
• Dynamic Type: Test larger text sizes to catch clipped content, overlapping controls, and layouts that no longer adapt correctly.
• Orientation changes: Verify that focus and reading order remain logical when the device switches between portrait and landscape.
• Gesture-dependent interactions: Check custom gestures and controls that may behave differently on physical hardware.
• End-to-end flows: Test login, forms, checkout, navigation, and other critical journeys with accessibility features enabled from start to finish.

The two approaches work best together. Use Accessibility Inspector during development to catch issues quickly, then use real devices to verify how the app behaves when accessibility features are part of the complete user experience.

Conclusion

Accessibility Inspector is a useful first line of defense for iOS accessibility testing. It helps you inspect labels, traits, values, focus behavior, contrast, and other properties that affect how assistive technologies interpret the interface.

But passing an audit does not mean the app is fully accessible. Problems can still appear during complete user flows, especially with VoiceOver, Dynamic Type, custom controls, dynamic content, and focus changes.

A stronger testing approach is to use Accessibility Inspector during development, then validate critical journeys with assistive technologies on real devices. That combination helps you catch both configuration issues and the interaction problems users are more likely to face in practice.