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 occasionally get this error in Xcode’s console: Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context. What does this mean, and how can I resolve it? Googling it doesn’t turn up any results. This doesn't crash the app - it’s just an error diagnostic that I see in the Xcode console. The app keeps running before and after the issue. Is there a way I can set a breakpoint to catch this where it happens?

Feedback number: FB20451665 When building with Xcode 26, Voice Over is reporting an extra tab when swiping through tabs. Please see the sample project below: /* This is a Sample project to show that I believe there is a Voice Over bug in iOS 26. When swiping through tabs with Voice Over active, there always appears to be an extra tab. Here I have 5 tabs, when on tab one VO reads out tab 1 of 6, then tab 2 of 6, all the way to the last tab, when voice over reads out tab 5 of 6. Never tab 6 of 6. Is there a possibility that voice over is picking up the underlying `more` tab and reading that out? This has also been reportedly found in the Files app here: https://www.applevis.com/comment/195441#comment-195441 */ struct ContentView: View { var body: some View { TabView { /// Activating this has Voice over telling us there are 6 Tabs. Tab(RootTab.home.title, systemImage: "circle.fill") { Text("This is the \(RootTab.home.title.capitalized) screen") } .accessibilityLabel("\(RootTab.home.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.home.title.capitalized) tab") Tab(RootTab.diary.title, systemImage: "circle.fill") { Text("This is the \(RootTab.diary.title.capitalized) screen") } .accessibilityLabel("\(RootTab.diary.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.diary.title.capitalized) tab") Tab(RootTab.meals.title, systemImage: "circle.fill") { Text("This is the \(RootTab.meals.title.capitalized) screen") } .accessibilityLabel("\(RootTab.meals.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.meals.title.capitalized) tab") Tab(RootTab.knowledge.title, systemImage: "circle.fill") { Text("This is the \(RootTab.knowledge.title.capitalized) screen") } .accessibilityLabel("\(RootTab.knowledge.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.knowledge.title.capitalized) tab") Tab(RootTab.profile.title, systemImage: "circle.fill") { Text("This is the \(RootTab.profile.title.capitalized) screen") } .accessibilityLabel("\(RootTab.profile.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.profile.title.capitalized) tab") /// Activating this also has Voice over telling us there are 6 Tabs. // ForEach(RootTab.allCases, id: \.self) { tab in // // Text("This is the \(tab.title.capitalized) screen") // .tabItem { // Label(tab.title.capitalized, systemImage: "circle.fill") // } // .accessibilityLabel("\(tab.title.capitalized) tab") // .accessibilityHint("Double tap to open the \(tab.title.capitalized) tab") // } } } enum RootTab: CaseIterable { case home case diary case meals case knowledge case profile var title: String { switch self { case .home: "home" case .diary: "diary" case .meals: "meals" case .knowledge: "knowledge" case .profile: "profile" } } } } I'm curious if anyone else can see this issue, or if anyone knows of a workaround for it.

Hello, In our app we provide a button that initiates a phone call using tel://. For normal numbers, tapping the button presents the standard iOS confirmation sheet with Call and Cancel. If RTT is enabled on the device, the sheet instead shows three options: Call, Cancel, and RTT Call. However, when dialing a national emergency number, this confirmation dialog does not appear at all — the call is placed immediately, without giving the user the choice between voice or RTT. Is this the expected system behavior for emergency numbers on iOS? 
And if so, how does RTT get applied in the emergency-call flow — is it managed entirely by the OS rather than exposed as a user-facing option? Thanks in advance for clarifying.

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

I wrote this in the regular forums and they deleted it and told me to write it here because it was dealing with unreleased software. I read that Launchpad is disappearing in Tahoe and I have real concerns about that. For me, that is an accessibility issue. I have both memory problems and scanning problems. So having my apps organized into categories is extremely important to me. Just today I needed to find an app that I didn't remember the name of and I rarely use, but when I need it, it is important to me. Just to see if I could find it without launchpad, I scanned my applications folder and I couldn't find it. I went to launchpad and to the category I knew it was in and it was right there, easy for me to find. Please don't take away our organization options.

Is it possible to create a sandboxed app that uses accessibility permission? And if so, how do I ask the user for that permission in a way that is allowed by the App Store? Im creating a small menubar app and my current (rejected) solution is to create a pop-up, with link to Security & Privacy > Accessibility and the pop-up asks the user to manually add the app to the list and check the checkbox. This works in sandbox. Reason for rejection: "Specifically, your app requires to grant accessibility access, but once we opened the accessibility settings, your app was not listed." I know it's not listed there and it has to be added manually. But its the only solution I've found to this issue. Is there perhaps any way to add the app there programmatically? Im a bit confused since I've seen other apps in App Store that work the same way, where you have to add the app to the list manually. Eg. Flycut. :man-shrugging: I know about this alternative solution, and it's not allowed in sandboxed apps. It also adds the app to the accessibility list automagically: func getPermission() { AXIsProcessTrustedWithOptions([kAXTrustedCheckOptionPrompt.takeUnretainedValue():true] as CFDictionary). } Does anyone have a solution for this? Best regards, Daniel

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!

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

[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

[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button("Button 1", systemImage: "1.square.fill") { print("Button 1 tapped") } // ✅ Hit target is entire button Button { print("Button 2 tapped") } label: { Label("Button 2", systemImage: "2.square.fill") } // ❌ Hit target is smaller than button Button { print("Button 3 tapped") } label: { Image(systemName: "3.square.fill") }

Here is a simple view to demonstrate the issue struct ContentView: View { @State private var isPresented = false var body: some View { VStack { Button("Test") { isPresented = true } } .alert("Test", isPresented: $isPresented, actions: { Button("Delete All", role: .destructive) {} }, message: { Text("Are You Sure?") }) .padding() } }``` Which results in ![example alert]("https://developer.apple.com/forums/content/attachment/c6210120-d82e-4df5-a01a-fc5cb168e1bf" "title=Screenshot 2025-09-08 at 08.57.21.png;width=546;height=442") The destructive button is almost unreadable. WCAG score is 1.4, far below the minimum recommended 4.5. I found [this post](https://stackoverflow.com/q/66448869) on SO going back to Big Sur, but not on this forum. Any known workarounds (except for building my own dialogs, which I am trying to avoid)? Using confirmationDialog instead of alert does not make a difference.

I’m trying to customize the keyboard focus appearance in SwiftUI. In UIKit (see WWDC 2021 session Focus on iPad keyboard navigation), it’s possible to remove the default UIFocusHaloEffect and change a view’s appearance depending on whether it has focus or not. In SwiftUI I’ve tried the following: .focusable() // .focusable(true, interactions: .activate) .focusEffectDisabled() .focused($isFocused) However, I’m running into several issues: .focusable(true, interactions: .activate) causes an infinite loop, so keyboard navigation stops responding .focusEffectDisabled() doesn’t seem to remove the default focus effect on iOS Using @FocusState prevents Space from triggering the action when the view has keyboard focus My main questions: How can I reliably detect whether a SwiftUI view has keyboard focus? (Is there an alternative to FocusState that integrates better with keyboard navigation on iOS?) What’s the recommended way in SwiftUI to disable the default focus effect (the blue overlay) and replace it with a custom border? Any guidance or best practices would be greatly appreciated! Here's my sample code: import SwiftUI struct KeyboardFocusExample: View { var body: some View { // The ScrollView is required, otherwise the custom focus value resets to false after a few seconds. I also need it for my actual use case ScrollView { VStack { Text("First button") .keyboardFocus() .button { print("First button tapped") } Text("Second button") .keyboardFocus() .button { print("Second button tapped") } } } } } // MARK: - Focus Modifier struct KeyboardFocusModifier: ViewModifier { @FocusState private var isFocused: Bool func body(content: Content) -> some View { content .focusable() // ⚠️ Must come before .focused(), otherwise the FocusState won’t be recognized // .focusable(true, interactions: .activate) // ⚠️ This causes an infinite loop, so keyboard navigation no longer responds .focusEffectDisabled() // ⚠️ Has no effect on iOS .focused($isFocused) // Custom Halo effect .padding(4) .overlay( RoundedRectangle(cornerRadius: 18) .strokeBorder( isFocused ? .red : .clear, lineWidth: 2 ) ) .padding(-4) } } extension View { public func keyboardFocus() -> some View { modifier(KeyboardFocusModifier()) } } // MARK: - Button Modifier /// ⚠️ Using a Button view makes no difference struct ButtonModifier: ViewModifier { let action: () -> Void func body(content: Content) -> some View { content .contentShape(Rectangle()) .onTapGesture { action() } .accessibilityAction { action() } .accessibilityAddTraits(.isButton) .accessibilityElement(children: .combine) .accessibilityRespondsToUserInteraction() } } extension View { public func button(action: @escaping () -> Void) -> some View { modifier(ButtonModifier(action: action)) } }

When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } Is there a recommended way to resolve this issue so that the navigation title is always readable?

Hi guys, I'm facing an issue with the native interface to add a card into the wallet - does someone have some ideas on how to fix/work around that? STEPS TO REPRODUCE: Disable VoiceOver (Settings → Accessibility → VoiceOver → Off). Connect and confirm that you can navigate other iOS interfaces using an external keyboard. In any app, present a PKAddPassesViewController with a valid .pkpass file. When the Wallet “Add Pass” sheet appears, attempt to navigate using only the external keyboard (Tab/Arrow/Enter). Observe that focus does not move to the Cancel or Add buttons, and no elements receive keyboard focus. EXPECTED RESULT: All interactive elements in PKAddPassesViewController (e.g., Cancel and Add) should be fully keyboard accessible without requiring VoiceOver. Users should be able to navigate, select, and complete actions using only a hardware keyboard. ACTUAL RESULT: Keyboard navigation is not possible. No elements receive focus. Users cannot activate Cancel or Add buttons using keyboard input. The only way to interact is by touch or enabling VoiceOver, which does not satisfy keyboard accessibility requirements. IMPACT: Violates WCAG 2.1 Success Criterion 2.1.1 (Keyboard Accessible). Prevents keyboard-only users (including users with motor disabilities) from adding passes to Wallet. Affects users of external keyboards who rely on tab/arrow navigation. Creates an inconsistent accessibility experience compared to other iOS system modals.

Hello, It's impossible to manage hit area for textfield and it's already too small by default (detected with Accessibility Inspector). I'm tried to force with modifier "frame(minHeight: xxx)", the component change the height but the hit area is still in same size. Have to tips to fix this issue?

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.

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.

We added Accessibility Nurtition Label on App Store connect for our app https://apps.apple.com/us/app/mybell/id850549838 But it is not showing up on the App Store. It shows as published but not visible on App Store. What can be the reason?

accessibilityUserInputLabels is working fine with any view I tried this on. Meaning that the control can be toggled with the provided alternative names when using Voice Control. When setting this property on any UIBarButtonItem though, it seems Voice Control ignores the alternative names provided by setting accessibilityUserInputLabels. For comparison, accessibilityLabel works perfectly when set on UIBarButtonItem. Is anyone facing the same issue? Using Xcode 16.0 (16A242) on iOS 18

I am developing an app that requires user to turn on overlay permissions (with a prompt provided to the user) as well as accesibility settings. The goal is to display a floating button on screen, which reads screen content only when user taps on that button. It is not a persistant overlay because user can make floating button disappear by turning it off inside the app. I want to know if apple app store policies will be ok with this kind of feature and if there is anything particular I need to comply with to enable my app in the app store?