A Summary of the WWDC25 Group Lab - Accessibility At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for Accessibility. Accessibility Nutrition Labels are a really big step forward for the experience people have on the App Store to find apps that will work for them. How should developers get started with Accessibility Nutrition Labels? A good starting point is to review the Accessibility Nutrition Label evaluation criteria on App Store Connect Help. It's a concise document, roughly 10 pages, and you can approach it section by section after the introduction. Even with prior experience using accessibility features like VoiceOver, the criteria offer valuable insights that might not be immediately apparent. For those newer to accessibility, a good entry point might be one of the visual feature labels, such as Dark Interface, which is a popular and frequently used feature. Which accessibility features can I indicate support for in Accessibility Nutrition Labels? The accessibility features covered include support for assistive technologies like VoiceOver and Voice Control, media enhancements such as captions and audio descriptions, and display accommodations. These display accommodations cover options like larger text, dark interface, differentiating without color alone, sufficient contrast, and reduced motion. With the new Accessibility Nutrition Labels, will app store reviewers validate what we select? The Accessibility Nutrition Label can be edited at any time without requiring a new app submission. However, if an app inaccurately claims feature support, App Review may contact the developer and request an update to the label or the app. Are there any updates to tools for analyzing the accessibility of our apps? Although there aren't new updates this year, continued support for Accessibility Audits is available through Xcode's built-in Accessibility Inspector. XCTest also supports accessibility audits, enabling developers to test app accessibility with every build. These audits analyze aspects like contrast, dynamic type, text clipping, element labels, and more within each view. For a deeper dive, the "Perform accessibility audits for your app" session from WWDC 2023 is a valuable resource. What are accessibility features you wish more people integrated? Accessibility features encompassing user input labels optimized for voice control, keyboard navigation and shortcuts, and dynamic type support could be more used to benefit users. What were some of the biggest accessibility challenges your team encountered while developing Liquid Glass? Apple is known for its innovation and strives to deliver a high-quality experience for everyone. Accessibility is considered a core component of visual design from the outset. For example, the Liquid Glass design inherently supports reduced transparency and increased contrast. As design continues to evolve, user feedback submitted through Feedback Assistant is invaluable. How does Liquid Glass respond to contrast? Especially for text and low contrast environments. Content legibility is a crucial aspect of the Liquid Glass design. It inherently supports accessibility features like reduced transparency and increased contrast. Your feedback during the beta period and beyond is essential to ensuring Liquid Glass provides a great experience within your apps. What are some Apple apps that stand out for their accessibility? Apps like Keynote in the iWork suite offer groundbreaking VoiceOver features to enhance creative productivity for all users. Assistive Access makes core apps such as Messages, Photos, Camera, Phone, and Music more accessible. Podcasts provides transcripts to broaden its reach, and frameworks like SwiftUI ensure that apps built with the latest UI frameworks have excellent built-in accessibility.

I have some doubts about how VoiceOver handles focus when the screen updates. When a new UIViewController is pushed onto a UINavigationController or presented modally, how does VoiceOver decide which element to focus on? Is there a way to control or customize this behavior? In a UISplitViewController, when an item is selected in the primary view controller, the focus should shift to the relevant content in the secondary view controller. How can we ensure that VoiceOver correctly moves focus to the right element in the secondary panel?

Hi everyone, My team and I are developing an accessibility-focused VisionOS app (MindTap) as part of a university project, aiming to support individuals with Locked-In Syndrome using Brain-Computer Interface (BCI) signals to trigger interactions (e.g., tapping) within the Apple Vision Pro environment. Problem 1: Simulating Eye Tracking in Simulator We are testing onHover with Send pointer to the device under I/O > Input in the simulator, and while it mostly works (a bit laggy), we found that onHover won't function on the actual Vision Pro hardware. From what I understand, we should be using FocusState for proper gaze interaction, but testing this requires the physical device. Is there any workaround or official Apple-recommended way to simulate Focus-based gaze detection without a real Vision Pro? Problem 2: WebSocket-triggered "Click" doesn't work outside the app We successfully use WebSocket to send a custom signal (a "1" from the brain signal device) to trigger an action inside our app. However, when the user opens a third-party app like Apple News, the WebSocket-triggered "click" no longer works. We suspect this is due to sandbox restrictions or lack of system-level permissions. Is it possible in anyway to: Trigger interaction events outside the app using custom input (like BCI via Websocket)? Access system-wide click/tap simulation APIs from within VisionOS apps Integrate this with accessibility services (like Voice Control or AssistiveTouch) We'd appreciate any official guidance or tips from others building similar accessibility apps with alternative input methods in VisionOS. Thanks in advance for any insight you can provide!

I've just received an email from Apple regarding the Global Accessibility Awareness Day and some forthcoming sessions to promote their accessibility features. What a joke. For many years, Apple refuses to provide the most basic accessibility requirement on macOS: LET USERS DISABLE ALL NON-CONSENSUAL UNSOLICITED ANIMATIONS AND OTHER UI CONVULSIONS. The scourge of animations started from macOS Lion. Yes, many of them can be, fortunately, disabled through some obscure Terminal commands (that is, if the user is lucky enough to discover them on some obscure internet resources). The "Reduce motion" control in System Settings is a fake option that doesn't do anything. And there are two most glaring accessibility violations that cannot be disabled: Scroll bar rollover highlight effect introduced on macOS 10.7.3. Every time you move the cursor over a scroll bar, the bar gets highlighted. It results in bringing the user's attention to random scroll bars for no reason whatsoever just because the cursor happens to pass over the bar at some point. HUNDREDS of unnecessary, annoying events of distraction daily! Expand/collapse animation of NSOutlineView (such as when we open/close a folder in the list view in the Finder, as well as any other app that's using outline views). It's extremely annoying, distracting, and time-wasting. All feedback submitted about this through the years remains mostly ignored (except for a few cases where I received some ridiculous replies from employees who, apparently, are barely familiar with Macs in general). Apple does NOT care about accessibility. Not only this, but it's obvious that Apple is, in fact, intentionally abusing those users who can't tolerate distracting, time-wasting animations and UI convulsions.

Hello, I had submitted a question to clarify which components have accessibility APIs that trigger haptics for VoiceOver users https://developer.apple.com/forums/thread/773182. The question stems from perhaps a more direct question about specific components: do tablists and disclosures natively intend to include haptics or screen reader hint or other state or properties to indicate to screen reader users where the component begins or ends? In some web experiences there are screen reader hint text stating "end of..." or "entering" as a way to define the boundaries of these inline dialogs. I had asked about haptics in the prior thread because I do not recall natively implemented version of this except in some haptic cues but have not experienced them consistently so I am not sure if that is an intended native Swift implementation or perhaps something custom.

I'm reposting here my FB17602742, submitted yesterday: The strong wording of this message comes from years of Apple ignoring the needs of users who can't tolerate UI animations and convulsions. At this point, it's clear that Apple is either intentionally harming users like me or simply doesn't care about meeting even the most basic accessibility standards on macOS. Yes, many UI animations and convulsions can, fortunately, be disabled - but not through straightforward UI controls. Instead, users are forced to look for obscure Terminal commands found scattered across the Internet. The "Reduce motion" checkbox in System Settings is simply a fake control that doesn't do anything - instead of actually disabling all UI animations and convulsions. What's worse, two of the most offensive UI animations cannot be disabled at all. Apple has consistently dismissed requests to let users disable the following UI animations: Scroll bar rollover highlight effect (introduced on macOS 10.7.3). Every time the cursor passes over a scroll bar, it gets highlighted. This draws the user's attention to random scroll bars for no reason - just because the cursor happened to pass over them. It results in HUNDREDS of unnecessary, annoying events of distraction daily!
 Expand/collapse animation of NSOutlineView (e.g., when opening/closing folders in the list view in the Finder, or any other app using outline views). This animation is extremely distracting, irritating, and time-wasting. Global Accessibility Awareness Day is approaching. Dear Apple, Please adhere to the most basic accessibility standards. Stop the needless suffering of countless users like me. Let us disable the two aforementioned UI convulsions. Thank you for your attention to the issue.

I have an ongoing activity in progress. Think of: a delivery in progress house internet reboot in progress some water / electricity / internet / tv outage. (food) order processing I want to show a persistent toast message above the tab bar, across all tabs and screens across the app. It could take 15 minutes until the activity is finished. Obviously there's a challenge of: accessibility content overlaying with each other extra engineering effort. What we've thought of doing is: Option1: show a toast message, but when a modal is presented then it presents on top of the toast message. The toast message no longer updates itself. Once the modal is finished, then the toast message re-appears and continues to update. Option2: keep the toast message across all tabs and modals and work through the challenges mentioned Question: What are some other design approaches that could be taken to persist an ongoing activity (much like 'Live Activity', but just across the app when it's in foreground) or what are some design reasons that the two options considered are bad?

I have screen in my app that can represented by following layout, I would like this screen to be possible to navigate with full keyboard access but there is unexpected behavior: Path: Tap "Tab" on keyboard -> whole scrollview is targeted and inside the first button1 is selected. Arrow down -> selection changes to button3 Arrow up -> selection changes back to button1 So button2 is always skipped, there is no way to navigate to it by arrows left/right. Using Tab+F and searching "button2", button2 is correctly selected, so it's selectable but for some reason not findable by going through elements. Putting empty text in Text views cause buttons to be vertically aligned and then everything works correctly but it is not an option. public struct BugReportView: View { public var body: some View { ScrollView { VStack(spacing: .zero) { Button("button1", action: { }) HStack { Text("some text") Text("some text2") Button("button2", action: { }) } Button("button3", action: { }) } } } }

Hi! I'm working on an application where I'd like VoiceOver to give each element of a tab bar the "Tab" trait. I'm testing this using the Accessibility Inspector. Essentially, I'd like to replicate the behavior of how Safari identifies each of its tabs as a "Tab" (I've attached a photo below). How exactly is this accomplished? I've tried using the .isTabBar trait to designate the child objects as "Tabs", but this doesn't seem to be working and I've struggled to find documentation about this. For additional context, these child items are Buttons, and I would like to have the .isButton trait essentially replaced by something like an .isTab trait. Not sure if this is actually possible or not, but curious how the Accessibility Inspector recognizes this in Safari.

The accessibility nutrition labels seem like a great feature. I don't see keyboard access mentioned, are there plans to add this into the accessibility nutrition labels? To emphasise that keyboard accessibility is not just for desktop computers, apps need it too.

I have two overlay views on each side of a horizontal scroll. The overlay views are helper arrow buttons that can be used to scroll quickly. This issue occurs when I use either ZStack or .overlay modifier for layout. I am using accessibilitySortPriority modifier to maintain this reading order. Left Overlay View Horizontal Scroll Items Right Overlay View When voiceover is on and i do a single tap on views, the focus shifts to particular view as expected. But for the trailing overlay view, the focus does not shift to it as expected. Instead, the focus goes to the scroll item behind it.

I am building a language learning app for a Unlisted Primary Language. Any suggestions or heads ups? My plan is to select english and go with it. Its unfortunate that I have to list a language learning app incorrectly and a tag for that language probably does not exist across the apple system.

Amogst the two languages my app would have lets say 10% and 90%. I am launching an app for a unlisted Primary Language. I consider whatever is inside the app as the primary and that wont be English. The secondary language

Once Accessibility Nutrition Labels are evaluated and published, is there any location or format to keep data on the evaluated content? And how will the App Review process work for this new feature? I have not yet seen any apps in the App Store with this section published live despite it being available in the App Store Connect currently so I'm curious about the process on Apple's side. My team is still evaluating but plans to publish soon.

Double-tap three fingers and drag to change zoom” should suppress “Three Finger to Drag”. Currently these gestures are triggered simultaneously, for no real reasons. I saw different behaviors for different environments, but none is desired. Current and desired behavior: This seems an issue so I filed a feedback.

[Also submitted as FB20262774. Posting here in hopes of saving someone else from burning half a day chasing this down.] Dynamic scaling of an Image() in a Button(), incorrectly decreases when transitioning from XXX Large to AX 1 accessibility text sizes, instead of continuing to grow as expected. This occurs both on device and in the simulator, in iOS 18.6 and iOS 26. Repro Steps Create a project with sample code below Show the preview if not showing In Xcode Preview, click Canvas Device Settings and change Dynamic Type from XXX Large to AX 1 Sample Code struct ContentView: View { var body: some View { VStack(spacing: 30) { Text("Button Image Scaling Issue") .font(.system(size: 24, weight: .semibold)) Text("Switch dynamic type from **XXX Large** to **AX 1**. The **Button** icon shrinks while the **No Button** icon grows.") .font(.system(size: 14, weight: .regular)) TestView(title: "No Button", isButton: false) TestView(title: "Button", isButton: true) } .padding() } } struct TestView: View { let title: String let isButton: Bool var body: some View { VStack { Text(title) .font(.system(size: 16)) .foregroundColor(.secondary) if isButton { Button {} label: { Image(systemName: "divide") .font(.system(.largeTitle)) } .buttonStyle(.bordered) .frame(height: 50) } else { Image(systemName: "divide") .font(.system(.largeTitle)) .foregroundColor(.blue) .frame(height: 50) .background(Color.gray.opacity(0.2)) } } } } Expected Result Both the button and non-button images should continue to scale up proportionally when moving to larger accessibility text sizes. Actual Result When going from XXX Large to AX 1… Non-button image gets larger ✅ Button image gets smaller ❌ Screen Recording System Info Xcode Version 26.0 (17A321) iOS 26.0 and 18.6

Japanese “Hattori” TTS voice missing from Settings > General > Read & Speak > Voices > Japanese on iOS 26 Steps: Open the path above → “Hattori” is not listed and cannot be downloaded Expected: Hattori is available to download and select Actual: Hattori is absent from the catalog Regression: Was available on iOS 18.x on the same device

I'm encountering an issue with system accessories in UICollectionViewCells after overriding the trait collection. Specifically, the accessories are misaligned and shifted downwards. This issue occurs when using setOverrideTraitCollection (other trait override methods produce the same result). Interestingly, this doesn't happen with all accessories; for example, the disclosureIndicator is scaled correctly. If I don't use setOverrideTraitCollection (or other trait override methods), the system accessories scale as expected. Here's a code snippet demonstrating the issue. I have a "Fix Size" button that overrides the trait collection to a UITraitCollection with a UIContentSizeCategory of large. The "Follow Settings" button resets the trait collection, allowing the views to scale according to the system settings. import UIKit class ViewController: UIViewController { let button: UIButton = { let button = UIButton(type: .system) button.setTitle("Fix Size", for: .normal) return button }() let buttonRe: UIButton = { let button = UIButton(type: .system) button.setTitle("Follow Settings", for: .normal) return button }() var listItems: [Int] = [1, 2, 3, 4, 5] var collectionView: UICollectionView? override func viewDidLoad() { super.viewDidLoad() button.addTarget( self, action: #selector(ViewController.buttonTapped), for: .touchUpInside ) buttonRe.addTarget( self, action: #selector(ViewController.buttonTappedToRe), for: .touchUpInside ) view.backgroundColor = .white view.addSubview(button) view.addSubview(buttonRe) setupCollectionView() if let collectionView = collectionView { view.addSubview(collectionView) } } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() collectionView?.frame = CGRect( x: 0, y: 0, width: view.bounds.width, height: view.bounds.height - 100 ) button.frame = CGRect( x: 0, y: view.bounds.height - 100, width: view.bounds.width / 2, height: 50 ) buttonRe.frame = CGRect( x: view.bounds.width / 2, y: view.bounds.height - 100, width: view.bounds.width / 2, height: 50 ) } @objc func buttonTapped() { setOverrideTraitCollection( UITraitCollection(preferredContentSizeCategory: .large), forChild: self ) } @objc func buttonTappedToRe() { setOverrideTraitCollection(nil,forChild: self) } private func updateCollectionViewLayout() { guard let collectionView = collectionView else { return } collectionView.collectionViewLayout.invalidateLayout() collectionView.performBatchUpdates(nil) collectionView.reloadData() } private func setupCollectionView() { var config = UICollectionLayoutListConfiguration(appearance: .insetGrouped) config.trailingSwipeActionsConfigurationProvider = { [weak self] indexPath in let deleteAction = UIContextualAction(style: .destructive, title: "Delete") { [weak self] _, _, completion in self?.deleteItem(at: indexPath) completion(true) } return UISwipeActionsConfiguration(actions: [deleteAction]) } let layout = UICollectionViewCompositionalLayout.list(using: config) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) collectionView.delegate = self collectionView.dataSource = self collectionView.register(UICollectionViewListCell.self, forCellWithReuseIdentifier: "cell") collectionView.isEditing = true self.collectionView = collectionView } private func deleteItem(at indexPath: IndexPath) { listItems.remove(at: indexPath.item) guard let collectionView = collectionView else { return } collectionView.deleteItems(at: [indexPath]) } override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) { super.traitCollectionDidChange(previousTraitCollection) if previousTraitCollection?.preferredContentSizeCategory != traitCollection.preferredContentSizeCategory { updateCollectionViewLayout() } } } extension ViewController: UICollectionViewDataSource { func numberOfSections(in collectionView: UICollectionView) -> Int { return 1 } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { return listItems.count } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "cell", for: indexPath) as! UICollectionViewListCell var content = UIListContentConfiguration.valueCell() content.text = "Item \(listItems[indexPath.item])" cell.contentConfiguration = content cell.accessories = [.delete( options: UICellAccessory.DeleteOptions( reservedLayoutWidth: .custom(50) ) )] return cell } } extension ViewController: UICollectionViewDelegate { func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) { collectionView.deselectItem(at: indexPath, animated: true) } } The attached screenshot illustrates the misalignment that occurs after tapping the 'Fix Size' button, with the system accessibility text size set to accessibilityExtraExtraExtraLarge setting Has anyone else experienced this issue or have suggestions on how to resolve it? Any help would be greatly appreciated!

Accessibility Voiceover is not treating navigation bar left button as first focused element. If we navigate from A->B then the focus is going to first element inside the B view not to the back button or B view's navigation title. If we post accessibility notification, in onAppear of B, focus is not shifting. but it will read back button first, and then read the B view's content item. it does't focus to back button in swiftUI. how should I do? if I want to focus on the navigation item back button or navigation title. my understanding is the system prioritizes the first focusable element in the view hierarchy. but The navigation bar (including the close button and title) is managed separately by the system. It is not part of the main view hierarchy, so it does not automatically receive focus unless explicitly set. if my thoughts are right, it seems a little strange. Why did you design it this way? Can you tell me your thinking? Thanks

Hello, Whenever I put accessibility focus on an image and if image has some text in it, voiceover reads that text along with image's accessibility label. Is there a way to programmatically turn off text recognition on images for accessibility? I couldn't find any relevant accessibility API's that could help here. Thanks!