A few years back, I was reviewing a PR for a junior dev who had built a gorgeous custom "Delete" button for a messaging app. He'd used a custom SVG of a trash can, styled it perfectly, and it looked sleek. But when I ran the app with VoiceOver turned on, the screen reader just said "Button." That was it. No context, no action, just "Button." The dev was confused; he told me, "But the icon is clearly a trash can!" It was a humbling reminder that if you aren't using assistive technology yourself, you're essentially guessing how your app feels to millions of users.

You don't actually have to keep VoiceOver running on your physical device all day to catch these mistakes. That's where the Xcode Accessibility Inspector comes in. It's a standalone tool that lets you "peek" into the accessibility layer of your app—both in the simulator and on a connected device—without having to manually navigate through every single menu with gestures.

Interrogating the Accessibility Tree

When you launch the Accessibility Inspector (found under Xcode > Open Developer Tool), you'll see a target selector. Once you point it at your running app, you can hover over elements to see exactly what the system sees. I usually start by clicking the inspection target (the crosshair icon) and clicking on a specific UI element, like a "Submit" button in a checkout flow.

The Inspector reveals the Label, Value, Traits, and Hint. If you're looking at that trash can button from my earlier story, the Inspector would show a blank Label. In SwiftUI, this is your cue to add an .accessibilityLabel("Delete Message") modifier. I find it incredibly helpful to see the "Traits" section too; if a view is meant to be a button but is missing the `.isButton` trait, the Inspector will make that glaringly obvious, saving you from a bug that would be hard to track down just by looking at the visual UI.

Running an Automated Audit

Manual inspection is great for specific components, but auditing a whole screen is tedious. This is why the "Audit" feature is your best friend. In the Inspector, there's an Audit button (the little checklist icon). When you trigger this, Xcode scans the current screen for common accessibility failures.

It doesn't catch everything—it can't tell you if your label is confusing or poorly written—but it's fantastic at catching technical gaps. It will flag elements with missing labels, insufficient contrast ratios between text and background colors, or elements that are too small to be easily tapped. I make it a habit to run an audit on every new screen before I even think about opening a Pull Request. It's much less embarrassing to fix a contrast issue yourself than to have a senior engineer or a QA tester point it out in a review.

Verifying the Focus Order

Accessibility isn't just about labeling; it's about flow. If a user is swiping through your app, they expect a logical progression—usually top-to-bottom, left-to-right. However, complex layouts with ZStack or absolute positioning can sometimes scramble this order.

Using the Inspector, you can simulate the navigation flow to see which element gets focus next. If you find that the focus jumps from the "Header" straight to the "Footer," skipping the main content entirely, you know you need to intervene. In SwiftUI, you can use .accessibilitySortPriority() to nudge the system in the right direction. I've spent hours debugging "invisible" UI bugs only to realize the elements were there, but the accessibility focus was just skipping right over them.

📋 Practical Task

Fixing the Order Summary Accessibility Gap

You have been handed a "Order Summary" screen in a shopping app. Visually, it looks great, but the Accessibility Inspector has flagged three major issues that need to be resolved in the code:

• The "Remove Item" button is a simple Image(systemName: "xmark.circle.fill") and is currently being read by the system as "xmark circle fill button."
• The "Total Price" text is a custom light-grey color on a white background, and the Inspector's Audit tool is flagging it for "Insufficient Contrast."
• The screen has a "Promo Code" field and a "Checkout" button, but the focus order is jumping from the Promo Code field directly to the Bottom Navigation bar, skipping the Checkout button entirely.

Your Task: Modify the SwiftUI view to provide a descriptive accessibility label for the remove button, update the text color to meet WCAG contrast standards, and use .accessibilitySortPriority() to ensure the Checkout button is focused before the navigation bar.