Accessibility Technologies Group Lab

A core technologies evangelist and a panel from the accessibility engineering, quality, and product marketing teams introduce themselves and highlight what's new for accessibility in the 27 releases: VoiceOver image descriptions and Live Recognition enhancements, a more personalized Accessibility Reader, more intuitive Voice Control, automatic subtitles in personal videos, and Vehicle Motion Cues coming to visionOS.

Test with Dynamic Type and large text alongside different screen sizes — the two go hand in hand. Design your UI to lay out dynamically for the user's chosen font size, and be prepared to reflow elements at accessibility text sizes rather than only scaling them.

You don't need experts in every assistive technology to ship a great experience. Start with VoiceOver: it's approachable and many technologies share the same backend accessibility APIs (elements, labels), so a strong VoiceOver experience carries much of Switch Control, Voice Control, and Full Keyboard Access for free. The extra per-technology API surface is mostly polish. Where possible, get feedback from real users to refine further.

Removing the image trait stops VoiceOver from appending its own generated description, leaving just your accessibility label. But consider not doing so: a subtle sound distinguishes your alt text from the auto-generated one, and the system description lets blind users ask follow-up questions and get more out of the image — valuable for art that would otherwise be inaccessible to them.

Accessibility Reader is a strong fit — a system-wide tool that reformats any long-form content to a reader's preferred style and integrates with Spoken Content. Image descriptions and Image Explorer help with charts and data-rich images, not just photos. More broadly, start with Dynamic Type to get your feet wet, then layer on VoiceOver support and accessibility labels.

Use accessibility notifications. Layout Changed suits smaller UI updates (like a button changing in place); Screen Changed is for whole-screen changes. You can pass an element to move VoiceOver focus, but use that sparingly so you don't yank focus around. For a completion announcement, the Announcement notification speaks a message without moving focus.

No new text-to-speech API this year, though there are backend improvements. If you need specific API additions, file them as feedback requests. Related note: Dynamic Type is now available on tvOS, so tvOS developers should get familiar with good large-text layout practices.

Accessibility Nutrition Labels let users know which accessibility features an app supports before they download it, so they can tell upfront whether it works with the assistive technologies they rely on. They also give developers a way to distinguish their apps and a concrete set of criteria to test and evaluate against. A prior WWDC session covers how to prepare and evaluate your app for them.

There's a new XCTest API to drive VoiceOver on an iOS device from a Mac, and to the panel's knowledge it should work in the Simulator in seed one. Behavior in the current beta may be a bug — bring specifics to the developer forums (an Accessibility Q&A was scheduled) and the filed feedback will be noted.

The biggest difference on the Mac is user expectations: Mac users often multitask and rely on accelerators. Get real user feedback and prioritize keyboard accelerators — hotkeys to jump to sections, the inspector, or the sidebar — which meaningfully speed up VoiceOver users on macOS.

Custom actions are the default answer, but on the Mac users tend to skip them, so reserve them for accelerator-style "pro" features. For important actions like hover behaviors, expose real, discoverable buttons instead. In SwiftUI, accessibility representation lets you replace a view's accessibility entirely — e.g. present one visual control as several distinct accessible buttons.

There's no single solution — the strength is breadth. Options that reduce reach or reliance on hands include Reachability, Voice Control, Head Tracking, Eye Tracking, Sound Actions, and Switch Control; and for those who do touch the device differently, Touch Accommodations and AssistiveTouch, with a new setup flow this year. The right combination depends on the individual user.

Two cognitive-accessibility features stand out. Guided Access keeps someone within a single app experience — useful for staying in a favorite book, show, or FaceTime call without wandering elsewhere. Assistive Access is a simplified visual language with large icons, larger default text, and bigger touch targets that pares an app down to its core controls.

The panel noted drag-and-drop accessibility varies significantly between iOS and macOS and may not be fully wired up for VoiceOver in the current beta. Rather than guess, they recommended taking the specific case to the developer forums, ideally noting the target platform.

The feature isn't available in the iOS 27 beta yet, so integration details aren't ready to share. Watch for more information when the APIs ship.

Wrap reusable views (labels, icons, buttons) so that whoever adopts them must supply an accessibility identifier and label, and add checks to enforce it. This yields concrete, stable labels for testing and keeps identifiers consistent across your code and test suite — especially important for symbol- or icon-based buttons that otherwise lack meaningful labels.

Designing for accessibility from day one produces a fundamentally better result than bolting it on at the end. It needn't be the main focus — just check each thing you build with VoiceOver as you go, carry accessibility through research and wireframing, and treat it as a continuous habit across development and testing rather than a final pass.

Just as a great SwiftUI app needs per-platform tuning to feel right on iPad or Mac, accessibility needs per-platform testing too. Fire up VoiceOver on each platform — macOS in particular has different nuances and user expectations — rather than assuming an iOS pass covers everything.

The voices used for VoiceOver are specifically tailored and tuned for screen-reader use, where users often run speech at high rates.

Automated testing is the most effective guard. XCUITest relies on the accessibility hierarchy across Apple's platforms, so an inaccessible app tends to fail its UI tests. Add assertions that check for accessibility labels, and use the new API for driving VoiceOver element-to-element to validate that it speaks the right thing. Automation gets you most of the way there.

Terminal accessibility improved notably — VoiceOver can move to the visible beginning, access marks better, and read tab-autocomplete suggestions. There are more Xcode VoiceOver bug fixes in seed one, with further work ongoing. SwiftUI is also a big win for blind developers, replacing drag-based interface building with code.

visionOS offers alternatives to gaze-based interaction. Pointer Control lets someone use a part of their body — head, finger, or wrist as an anchor — as the pointer instead of their eyes. A dedicated visionOS accessibility WWDC session covers these input alternatives in depth.

A closing note of appreciation, echoing that assistive technologies benefit everyone, not only people who identify as having a disability. The host points developers to the developer forums and the Accessibility & Inclusion Q&A, feedback.apple.com for bugs and API requests, and accessibility@apple.com for enhancement requests and stories.