WWDC26: Accessibility Technologies Group Lab - Q&A
Direct answers from Apple Engineers during WWDC26
Accessibility is not a final checklist item. It is part of how people actually experience software: reading, navigating, understanding, controlling, testing, and trusting that an app will work for them before they even download it. And for many this feature will bring whole world back again. I recommend you to watch this session.
As usual, the goal is simple: make the questions easier to scan, easier to revisit, and easier to connect with real app development problems.
I tried to preserve the original wording and combine related answers where appropriate. However, some inaccuracies or mismatches are still possible.
Enjoy! And subscribe so you don’t miss the next Lab.
What is your best advice for testing usability? Accessibility Inspector to audit elements, Device Hub for testing across different screen sizes — any other advice?
When testing accessibility, screen size and text size should be considered together. Dynamic Type and Large Text often affect layout just as much as a smaller or larger device does.
A view that works visually at the default font size can fall apart when a user enables an accessibility text size. Sometimes that means labels wrap. Sometimes it means the layout should change entirely so controls remain understandable and tappable.
So in addition to using Accessibility Inspector and Device Hub, test with larger text sizes early. Make sure your UI is dynamic enough to adapt to both different device sizes and different user text preferences.
On most teams, accessibility testing means VoiceOver and then they call it a day. Switch Control, Voice Control, and Full Keyboard Access rarely get a pass. How does your team prioritize across assistive technologies when you cannot test everything? Which one do we most underestimate?
The honest answer is that many teams are in exactly that situation. Not everyone has the resources to test every assistive technology deeply. Starting with VoiceOver is still a very good first step.
VoiceOver testing is approachable: you can turn it on quickly and begin testing without extra hardware. It also gives a lot of value because many assistive technologies share the same underlying accessibility information: labels, traits, elements, grouping, and structure.
If your VoiceOver experience is strong, Switch Control and Voice Control often benefit from that work too. There are additional APIs for polishing those experiences, but the shared accessibility foundation matters most.
The panel also emphasized the value of real users. You can get far by testing yourself, but feedback from people who rely on these technologies can reveal problems and expectations you may not notice.
Is there any way to override or turn off the system-provided description of an image? I have an app that displays artwork, and VoiceOver reads my provided description immediately followed by the system description. I am using the accessibility label modifier on a SwiftUI image.
One possible technical workaround is to remove the image trait, which can stop VoiceOver from treating the element as an image and therefore stop the automatic image description behavior.
However, the panel cautioned against doing this too quickly. Removing the image trait may also prevent users from accessing newer image-description features, including the ability to ask follow-up questions about the image.
For artwork, the right answer can be nuanced. The artist-provided description may be the authoritative description, but an AI-generated description can still be useful for a blind user who wants a more literal sense of what is visually present.
VoiceOver plays a small sound before the generated description, so users can distinguish between your provided alt text and the system-generated description. That distinction may be enough in some cases, and preserving the image trait may give users more options.
I’m a third-year medical student building an EHR for underserved areas. Part of it is a patient portal. What new accessibility technologies and features announced at WWDC would be helpful for patients that I can fold into development now?
Accessibility Reader is a strong fit for patient-facing long-form content. It is system-wide and lets users customize a reading experience that works for them, then apply that style to content from different apps.
Image descriptions and Image Explorer can also help when a portal contains charts, medical imagery, or data-rich visual content. These tools are not only for photographs; they can also help users understand charts and visual information.
More generally, start with Dynamic Type. A patient portal will likely contain dense and important text, so supporting larger text sizes well is a high-impact accessibility foundation.
After that, VoiceOver support gives another large win. Add useful labels, make sure navigation order makes sense, and test important patient workflows with VoiceOver enabled.
In many places in my app, the user taps a button that triggers a network request. For sighted users I show a progress view in place of the button, then replace the button content. How do I make that accessible to iOS VoiceOver users? I’d like VoiceOver to announce when the action completes.
Use accessibility notifications. For smaller layout changes, a layout-changed notification can tell VoiceOver that something in the UI changed. For larger transitions, a screen-changed notification may be more appropriate.
You can also pass an accessibility element to move VoiceOver focus, but do that carefully. Users do not want their focus pulled around unpredictably.
If the main need is simply to tell the user that the action completed, an announcement notification may be the clearest option. You provide a string and VoiceOver speaks it.
The key is to communicate the state change without making the experience noisy or stealing focus unnecessarily.
Are there any updates to the text-to-speech APIs this year?
The panel was not aware of new text-to-speech APIs in this release.
There are improvements on the backend, but no new developer-facing API was called out in the lab. Developers who need specific text-to-speech API changes should file feedback with concrete use cases.
Dynamic Type is now available on tvOS. What should tvOS developers think about, and what does the work look like to get ready?
Start by learning the current best practices for large text. When accessibility font sizes are enabled, your layout may need to do more than scale text. It may need to reflow.
The panel specifically recommended the new WWDC session about Large Text on tvOS. Older Large Text sessions are also useful, even if they focus on iOS, because the same principles apply: avoid fixed assumptions, make room for content growth, and test with real accessibility text sizes.
Accessibility Nutrition Labels also now become relevant for tvOS in this area, because developers can report Large Text support for tvOS apps.
We are very excited about Accessibility Nutrition Labels. Please talk about how valuable they are and any details you would like to expand on.
Accessibility Nutrition Labels help users understand whether an app is likely to work for them before they download it. For many users, downloading an app without accessibility information can feel like gambling.
For developers, the labels are also a way to communicate work that might otherwise be invisible. If your team invested in VoiceOver, Large Text, subtitles, contrast, reduced motion, or other accessibility support, the label lets users see that commitment.
The panel also noted that the guidelines themselves are valuable. They give teams concrete criteria to evaluate against, which can help teams advocate internally for accessibility work.
One example shared was a developer at a large organization who used the label effort to help get support inside the company. That kind of visibility can turn accessibility from an afterthought into a visible product quality goal.
I was excited to see that there is a VoiceOver option in the Xcode 27 beta Device Hub, but when I tried to use it, it did not do anything. Is it intended to work on simulators or only on physical devices? Is this the year we can test iOS VoiceOver on a Mac?
There is a new XCTest API that lets you test VoiceOver on an iOS device from a Mac. The panel believed it should also work in the simulator, but recommended taking specific failures to the forums and filing feedback.
The user already included a feedback number, and the panel said they would take note of it.
There is also an Accessibility forum Q&A, which is a good place to bring detailed issues around Device Hub, XCTest, VoiceOver, and simulator behavior.
We’re adding VoiceOver support to our macOS app. With this year’s accessibility updates, is there anything we should revisit? What’s the recommended way to test accessibility across different assistive technologies on Mac?
On macOS, user expectations are different from iOS. Mac users often multitask, use more keyboard shortcuts, and expect faster navigation across sections of an app.
For VoiceOver on Mac, think beyond labels alone. Consider accelerators: keyboard shortcuts, ways to jump to sidebars, inspectors, and important regions, and workflows that let users move efficiently.
Many of these are not VoiceOver-specific APIs. They are general Mac app affordances that greatly improve the experience for VoiceOver users and keyboard-heavy users alike.
For testing, use the accessibility shortcut. On macOS, VoiceOver can be toggled with Command-F5. If you have Touch ID, triple-pressing Touch ID opens the accessibility shortcut. Without Touch ID, Command-Option-F5 opens it.
For custom AppKit controls with context menus, hover actions, and custom buttons, what is the right way to expose these so VoiceOver users can discover and perform the same actions as mouse users?
Custom actions are often the default answer, but they have tradeoffs on the Mac because users may skip them or not expect them in every context.
If the actions are important, consider exposing them more explicitly. In SwiftUI, accessibilityRepresentation can let you expose a custom view as a different accessibility structure, such as multiple buttons instead of one complex visual control.
In AppKit, you can achieve similar results by implementing accessibility children and creating your own accessibility elements, though it is more manual.
Also consider keyboard shortcuts. If an action is useful for VoiceOver users, it may also be useful for power users and full-keyboard users. Be cautious with hover-only actions, because hidden UI can also be difficult for users with cognitive accessibility needs.
How does Apple design accessibility features for people with limited or no use of their hands or arms, including people with limb differences, paralysis, tremors, or temporary injuries?
Apple provides a range of options because different users with similar disabilities may prefer very different solutions.
Examples include Voice Control, Head Tracking, Eye Tracking, Sound Actions, Switch Control, AssistiveTouch, Touch Accommodations, and Reachability. Some users may avoid touching the device entirely. Others may touch it, but need the device to interpret touch differently.
Touch Accommodations now has a new setup flow in iOS 27. Instead of manually tuning every setting, users can go through a calibration activity, tap targets, and receive a recommended configuration.
The panel also highlighted on-device eye tracking on iOS. External eye trackers can be very accurate, but they require hardware and setup. Built-in eye tracking can make everyday situations much easier, including something as simple as changing entertainment on an airplane without needing help.
The larger principle is flexibility: Apple avoids boxing users into one input model and instead provides multiple paths so people can configure the device around their needs.
Could you mention some features made with neurodivergent people in mind?
Guided Access and Assistive Access are two major features designed with cognitive accessibility in mind.
Guided Access helps keep someone inside a single app or experience. For example, it can let someone stay in a favorite book, TV show, or FaceTime call without accidentally leaving that context.
Assistive Access provides a simplified visual and interaction model. It uses larger default text, bigger touch targets, simplified app experiences, and a clearer visual structure. Apple has brought more first-party apps into Assistive Access, including the TV app.
There are also APIs for developers to create optimized versions of their apps for Assistive Access. Beyond those two features, Screen Time, Speak Screen, Speak Selection, and Accessibility Reader can also be helpful for neurodivergent users.
SwiftUI has a new reorderable modifier. How do I make that accessible to VoiceOver? Dragging and dropping is not an idiom in VoiceOver.
The panel did not give a final answer in the lab. They noted that the experience may vary by platform and recommended bringing this to the developer forums.
Drag-and-drop accessibility can differ between iOS and macOS. iOS drag and drop generally works well with VoiceOver, while macOS may have different behavior and expectations.
For now, this is a good case for forum discussion and feedback, especially if the new SwiftUI reorderable modifier does not expose the right accessibility interaction in the current beta.
I would love to learn more about the new FaceTime video interpreting feature announced at WWDC. How can third-party apps integrate? How is the interpreting session initiated, and are there entitlements or API restrictions?
The feature is not available in the current iOS 27 beta, so the panel did not provide integration details.
The answer was to stay tuned for more information when the APIs become available.
For custom SwiftUI reusable views like labels, icons, and composite wrappers, what is the recommended way to expose stable accessibility identifiers for UI tests and Accessibility Inspector without misusing the accessibility label?
Do not overload the accessibility label with test-only information. Labels are for users.
For reusable views, one practical pattern is to require both an accessibility label and an accessibility identifier when the wrapper is created. That makes the API push callers toward doing the right thing.
You can also add checks so the label cannot be nil. This helps ensure that future reuse of the component still includes meaningful accessibility information.
For symbols, icon buttons, and other reusable controls, require a real accessibility label and a stable identifier separately. The label supports assistive technology users, while the identifier supports testing.
At the beginning of an app design project, what process do you recommend for making sure accessibility is built in from the start instead of bolted on later? How does that move from UX research and wireframing into Swift development, testing, and support for different assistive technologies?
The fact that you are asking the question is already a strong start. Accessibility is much easier when considered from day one instead of taped onto the app at the end.
At the design stage, learn how users of different assistive technologies might use a similar app. If you have resources for usability research with disabled users, use them. Real users will find issues and suggest improvements you may not think of.
For larger teams, showing the real user impact can be powerful. Seeing a VoiceOver user touch a control and hear nothing creates a human connection that abstract requirements often do not.
Make accessibility part of the same planning conversation as security and privacy. It should be one of the dimensions considered throughout the project.
During implementation, shared components and wrappers can enforce accessibility labels and identifiers. During late-stage polish, reserve time to refine the VoiceOver and Dynamic Type experiences after the UI has stabilized.
Finally, do not only measure impact by the number of users. Also consider criticality. A feature may affect fewer users but be absolutely essential for those users to use the app at all.
There are a lot of resources on accessibility for iOS, with fewer resources tailored to other targets. Are there platform-specific pitfalls to look out for when developing a universal app for macOS, iPadOS, watchOS, tvOS, and other platforms?
A universal app still needs platform-specific testing. If an app works well on iOS, it may still need adjustments for iPad, Mac, TV, or Watch.
Accessibility is the same way. Test VoiceOver on iOS, but also test VoiceOver on macOS if you ship a Mac app. User expectations are different. Mac users may expect keyboard shortcuts, inspectors, sidebars, and fast navigation. iOS users may rely more on hit testing and touch exploration.
So the pitfall is assuming one accessibility pass covers every platform. Shared SwiftUI code helps, but each platform has different interaction models and different accessibility expectations.
With these new improved AI voices, will any of them be available for VoiceOver?
VoiceOver voices are not just general-purpose system voices. They are specifically tuned for screen reader use, where people often listen at very high speech rates.
That means a voice that sounds natural in ordinary spoken content may not necessarily be the best fit for VoiceOver. The panel did not announce a simple “all new AI voices are available for VoiceOver” answer. Instead, they emphasized that VoiceOver speech has its own requirements and tuning.
Besides manual testing, how do you prevent accessibility regressions? What about approaches like accessibility snapshot testing or automated UI testing with accessibility assertions?
Automated UI testing is one of the strongest tools here because XCTest and XCUITest rely on the accessibility hierarchy across Apple platforms. If your accessibility hierarchy breaks badly, your UI tests may fail as a result.
You can also add explicit assertions for accessibility labels and other accessibility properties. For example, tests can check that important controls have labels and that the accessibility hierarchy exposes the elements your app depends on.
There is also a new VoiceOver testing API. It can start VoiceOver, navigate element by element, and validate what VoiceOver speaks or whether it reaches expected controls. That can be useful for smoke tests that verify VoiceOver can navigate key screen elements and does not encounter silent controls.
I’m a blind iOS developer. Are there any accessibility improvements in Xcode and developer tools in general this year?
Terminal accessibility has improved. VoiceOver can move to visible beginning, access marks better, and read tab-completion suggestions more reliably.
Xcode also has multiple VoiceOver bug fixes in the current seed. The panel noted that SwiftUI itself is a big accessibility win for blind developers because UI can be defined and edited in code, instead of relying on a visual interface builder workflow.
Xcode also has useful VoiceOver rotors for navigating code, including jumping between methods, errors, warnings, and variable names. The panel said there is still work to do and encouraged developers to keep filing feedback.
They also called out AI as a potential game changer for developer tools, especially because it can help summarize, inspect, and explain code in ways that may reduce the need to visually scan large files.
I’m curious if you have recommendations for making RealityKit or 3D content accessible.
RealityKit and spatial content need accessibility design too. The panel referenced prior WWDC material covering how to make RealityKit content accessible, including APIs for exposing spatial content to assistive technologies.
The main idea is that spatial or 3D content should not become invisible to users who rely on VoiceOver or other assistive technologies. You need to expose meaningful accessibility information for objects, interactions, and scene structure, not only render them visually.
The recommendation was to watch the dedicated session on making spatial content accessible, because it covers these APIs and design patterns in more detail.
Assistive technology is for everyone. I use VoiceOver and Dictation all the time even without a disability.
The panel highlighted this as an important point. Accessibility features often help far more people than the original audience they were designed for.
VoiceOver, Dictation, Large Text, captions, spoken content, and many other tools can be useful situationally, temporarily, or simply as a personal preference. This is one reason accessibility should be treated as core product quality, not a niche feature set.
🏆 Acknowledgments
A huge thank-you to everyone who joined and shared practical, thoughtful accessibility questions throughout the session. Your questions made the discussion useful for developers working on VoiceOver, Dynamic Type, Switch Control, Voice Control, Accessibility Nutrition Labels, Device Hub, macOS accessibility, AppKit, SwiftUI, cognitive accessibility, mobility access, testing, and universal app design.
The uploaded transcript does not include stable attendee nicknames for most questions, so the acknowledgments avoid inventing names. Question acknowledgments: the online WWDC audience who submitted and upvoted the Accessibility Technologies questions.
Finally, a heartfelt thank-you to Cole, Julia Sonen, Drew, Greg, Sil, and the accessibility team behind the scenes for leading the session, sharing practical guidance, and explaining how to build accessibility into app experiences from the start.