Swift Accessibility and Dynamic Type

How it works

Use semantic controls before adding custom accessibility. Labels name an element, values describe changing state and actions expose meaningful operations. Dynamic Type needs flexible layout, while VoiceOver focus is separate from ordinary keyboard focus. AccessibilityFocusState can move focus after a relevant change, but unexpected focus jumps can be disruptive.

Apple-only setup and review status

Create a separate iOS SwiftUI App learning project in a suitable Xcode version, choose an appropriate simulator/device and replace the generated app/view Swift source with this complete file. Keep one @main entry point. Widget and App Clip lessons explicitly require their own extension/clip targets instead; capability, purpose-string, entitlement and account steps in the lesson must be completed separately. No Xcode project, signing certificate, account or service was provisioned here.

Bhylu has no Swift browser runner. The JavaScript/Python editors do not run these sources; Apache, PHP and MySQL are not required. Downloads are source text, never executable teaching endpoints.

Download the complete accessibility.swift · Download all source files with hash checks

For the optional collection, save download-examples.mjs in a new folder and run node download-examples.mjs. A local preview uses node download-examples.mjs http://127.0.0.1:8000/examples/swift/. It refuses an existing bhylu-swift-examples folder and installs or executes no Swift automatically. Apple-only files remain separate Xcode learning examples, not a portable Swift package target.

Example

// Apple-only learning file: iOS 17+ target with a suitable Xcode SDK.
// Not compiled or run in this Windows/Linux review.
import SwiftUI


struct DemoView: View {
    @State private var count = 0
    @AccessibilityFocusState private var summaryFocused: Bool
    var body: some View {
        ScrollView {
            VStack(alignment: .leading, spacing: 24) {
                Text("Draft pieces: \(count)").font(.title)
                    .accessibilityLabel("Draft pieces").accessibilityValue(String(count))
                    .accessibilityFocused($summaryFocused)
                Button("Add draft piece") { count += 1 }
                Button("Read summary") { summaryFocused = true }
                Text("Draft only. Nothing has been booked or saved.")
            }.padding()
        }
    }
}

@main
struct WorkshopDemoApp: App {
    var body: some Scene { WindowGroup { DemoView() } }
}

Expected behaviour and manual checks

Manual check: use VoiceOver, large accessibility text sizes, keyboard/switch input where available and increased contrast. Confirm labels, values and reading order are meaningful. This is a proposed test procedure, not an accessibility clearance or executed result.

The layout can scroll when text expands, and ordinary Buttons already expose button semantics. The user explicitly requests summary focus rather than having every count update steal it. No information depends only on colour.