Bridging the Inclusion Gap: What I Learned from Apple's Accessibility Sessions

I create mobile and desktop apps in Swift and SwiftUI. For my Digital Accessibility course, I explored six WWDC sessions (2023–2025) on accessibility. I expected a checklist of APIs. What I got was a shift in how I think about the people using my software.

The Sessions at a Glance

Design Your App to Be More Inclusive (WWDC 2025) — the "inclusion gap" framework, four pillars: multiple senses, customization, Accessibility APIs, inclusion debt.

Make Your Mac App More Accessible (WWDC 2025) — VoiceOver containers, rotors, accessibility actions, keyboard navigation on Mac.

Evaluate Your App for Accessibility Nutrition Labels (WWDC 2025) — testing against Apple's App Store accessibility labels.

Catch Up on Accessibility in SwiftUI (WWDC 2024) — accessibility elements, modifiers, labels, drag-and-drop.

Get Started with Dynamic Type (WWDC 2024) — text scaling, layout adaptation, Large Content Viewer.

Perform Accessibility Audits for Your App (WWDC 2023) — automated audits in UI tests.

Developer Takeaways

1. Structure Your Accessibility Tree Deliberately

On macOS, VoiceOver navigates nested containers — the quality of that tree determines whether your app feels fluid or frustrating. The key API is .accessibilityChildren(_:) with three behaviors: .contain (named group to focus into), .combine (merge views into one element), .ignore (collapse and hide children).

My sidebar had no grouping — now I'm wrapping panels:

VStack {
    ForEach(presets) { preset in
        HStack {
            Text(preset.name)
            Button("Apply") { apply(preset) }
        }
        .accessibilityElement(children: .combine)
    }
}
.accessibilityElement(children: .contain)
.accessibilityLabel("Style Presets")

2. Custom Rotors for Power Navigation

Rotors let VoiceOver users jump between named element collections instantly:

.accessibilityRotor("Flagged Items") {
    ForEach(items.filter { $0.isFlagged }) { item in
        AccessibilityRotorEntry(item.title, id: item.id)
    }
}

3. Expose Hover-Only Interactions

Hover-only actions are invisible to VoiceOver, Switch Control, and Voice Control. The fix:

PageThumbnail(page: page)
    .accessibilityAction(named: "Bookmark") {
        toggleBookmark(page)
    }

4. Dynamic Type on macOS

Use system text styles, switch layouts at accessibility sizes via dynamicTypeSize, use @ScaledMetric for images, adopt the Large Content Viewer for toolbars.

5. Automate Accessibility Testing

One line in UI tests catches missing labels, low contrast, and clipped text:

func testAccessibilityAudit() throws {
    let app = XCUIApplication()
    app.launch()
    try app.performAccessibilityAudit()
}

Added to tearDown — caught two unlabeled icon buttons on the first run.

6. Nutrition Labels as a Quality Checklist

Sufficient Contrast, Dark Interface, Larger Text, Differentiate Without Color Alone, Reduced Motion, Voice Control, VoiceOver, Captions, Audio Descriptions — an excellent self-assessment even outside the App Store.

Design Takeaways

Disability Is a Spectrum

The question isn't "can a blind person use this?" but "can someone with some vision, some motor control still get value?"

The Inclusion Gap

Disability emerges from the gap between what a body can do and what the environment demands. Flexible layouts don't just serve accessibility — they make the interface more resilient for everyone.

Multiple Senses + Customization

Adapt the app to the person, not the other way around. Does every feature have a non-mouse alternative? Is any info conveyed through color alone?

Accessibility Starts at Design Time

Most problems are design-level decisions. Accessibility belongs in design reviews, not just code reviews.

Personal Reflection

What surprised me

The inclusion gap reframed everything. A text field that doesn't grow isn't a SwiftUI bug — it's a layout decision. Hover-only buttons aren't a missing modifier — they're a design pattern that assumes a mouse.

What I tested

VoiceOver on my own app: buttons as just "button," no sidebar grouping, hover actions invisible. performAccessibilityAudit() — four failures on the first run.

What I'm taking away

1. Test with VoiceOver regularly.

2. Track inclusion debt like tech debt.

3. Structure before decoration.

4. Design and code are the same conversation.

What changed my perspective

These sessions changed me from caring vaguely to understanding how much I was still missing. The most accessible version of my app will also be the best version for everyone.

Sources

Design Your App to Be More Inclusive — WWDC 2025

Make Your Mac App More Accessible — WWDC 2025

Evaluate Your App for Accessibility Nutrition Labels — WWDC 2025

Catch Up on Accessibility in SwiftUI — WWDC 2024

Get Started with Dynamic Type — WWDC 2024

Perform Accessibility Audits for Your App — WWDC 2023