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.

Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.

I would like to script my Mac to close a specific iCloud Tab of my choice that is open on my iPhone. This is for Accessibility reasons. Ideally, I’d prefer to do this without using GUI scripting. AppleScript methods only seem to see tabs in Windows Extensions also do not seem to have visibility of the other types of tabs I've tried many options so far, but all seem to not work and are also far too brittle even if they did. I have a feeling I'm missing something! 1. Toolbar Dropdown In Desktop Safari you can enable a toolbar button “iCloud Tabs” which when clicked shows a list of the tabs currently open on your other devices. If you hover one, an X appears which can be clicked to close the tab. When you next use Safari on the remote device that tab will be closed. If it’s already open and awake then the removal happens around one second later. It’s quick. (But I did try GUI scripting and I can get to the row in the outline in the popup, but I can’t get the cross to appear to click it) 2. Start Page they’re also listed on favorites:// “start page” but there are issues viewing all and no way to search them. There used to be a search field until Safari ~15. 3. Omnibar They’re also shown in omni/address bar, but getting the correct item to appear at all or in a predictable position is fragile. 4. Sidebar Another alternative to the favorites/"start page" layout. Same issues. 5. Modifying Safari Database directly Changes are not mirrored to the cloud. It seems Safari does a cloudd request that I can't do.

Looking to begin an accessibility vision app and I’m not having any luck locating properties or code that allows access to the display zoom. Has anyone worked with these areas before?

Hi, My first notarization submission has been stuck in "In Progress" for several hours with no status change. I'm wondering if it's being held for in-depth analysis given the nature of the app. The app is a macOS dictation utility triggered by a global hotkey. It captures audio input, transcribes it, and pastes the result at the cursor position in whatever app the user is focused on. Because of how it works, it relies on a combination of APIs that may be less common in typical submissions: continuous microphone access, programmatic clipboard manipulation, global keyboard event monitoring, and Accessibility APIs to inject text into the frontmost application. This is the first submission for this app, so there's no prior notarization history for the system to learn from. Is this the kind of profile that typically triggers in-depth analysis? Is there anything I should check or provide, or is waiting the right move here? Thanks

Hi, and apologies for a long post! We have created an app that enables wireless communication with FIDO2 devices over Bluetooth by creating virtual HID devices and translating the packages. In order to do this, we use the HIDVirtualDevice class as described here: https://developer.apple.com/documentation/corehid/creatingvirtualdevices We learned the hard way that this sample code does not work without the “com.apple.developer.hid.virtual.device“ entitlement, but with it, it behaves as expected. Now, our application has been rejected during Review, both by the initial App Review and the appeal to the App Review Board. The problem is that I can’t really figure out what the issue is. The first rejection states the following: The app requests access to Accessibility features on macOS but does not use these features for accessibility purposes. Specifically, the app uses Accessibility features for non-accessibility feature. (Please see attached screenshot) The attached screenshot is of the screen the app shows when requesting permissions, with this code: else if bluetoothManager.requirePermissions { GradientTitle(text: "PERMISSIONS \nNEEDED") Text( """ This application requires additional permissions to run. Open the settings menu to allow access before restarting the application. """ ) and a button with this action: if let url = URL( string:"x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility" ) { NSWorkspace.shared.open(url) } The requirePermissions boolean is set from here, let properties = HIDVirtualDevice.Properties( descriptor: VirtualDevice.fidoDescriptor, vendorID: VirtualDevice.vendorId ) if HIDVirtualDevice(properties: properties) != nil { await MainActor.run { self.requirePermissions = false } break } else { await MainActor.run { self.requirePermissions = true } When HIDVirtualDevice(properties: properties) is called, a system pop-up with App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. shows. I responded to the rejection by trying to argue that allowing you to use your device wirelessly does increase accessibility, and that this is the only purpose of the app. Their response was: Regarding 2.4.5, Accessibility usage. To resolve this issue, it would be appropriate to remove Accessibility usage for non-accessibility purposes. Should you require more assistance with resolving this issue, Apple Developer Technical Support is available to provide direct one-on-one support for discrete code-level questions. Please be sure to include any crash logs, screenshots or steps to reproduce this issue in your request. I contacted technical support and tried to explain the issue again, and got the following response: Guideline 2.4.5 - Performance The app requests access to Accessibility features on macOS but does not use these features for accessibility purposes. Specifically, the app uses Accessibility features for non-accessibility feature. Accessibility features are intended to help users with different capabilities interact with their devices and app. Apps may not use features designed to increase accessibility for other purposes. We understand that the reason for using Accessibility feature on macOS. However, the usage is not compliant with the provided guideline. The last sentence is not complete, and it’s hard to understand what the issue is, given that they have not actually responded to my arguments. My best guess right now is point 2.4.5 (v): 2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind: (v) They may not request escalation to root privileges or use setuid attributes. If this is the case, I can understand the rejection, although it’s strange they didn’t just say so then. If that is correct, given that the system pop-up and accessibility requirement also trigger when running their sample code (which creates a virtual keyboard), does that mean that no one using this class and framework can submit apps to the App Store? I never intended to use an accessibility framework, and I was quite surprised the first time the pop-up appeared. RIght now I'm just confused and dissapointed with the level of feedback from Apple, and would appreciate any help, either in providing a solution or just explaining what the specific issue is.

I am exploring the development of a utility app that provides real-time feedback to users based on their active screen content (e.g., providing text suggestions for various communication apps). To achieve this, I am looking at using ReplayKit and Broadcast Upload Extensions to process screen frames in the background via OCR. I have a few questions regarding the "Screen Recording" permission and App Store Review: Permission Clarity: Is it possible to trigger the Screen Recording permission request in a way that clearly communicates the "utility" nature of the app without the system UI making it look like a standard video recording? Background Persistence: Can a Broadcast Extension reliably stay active in the background while the user switches between other third-party apps (like messaging or social apps) for the purpose of continuous OCR processing? App Store Guidelines: Are there specific "Privacy & Data Use" guidelines I should be aware of when an app requires persistent screen access to provide text-based suggestions? I want to ensure the user experience is transparent and that the permission flow feels like a "helper utility" rather than a security risk. Any insights on the best APIs to use for this specific background processing would be appreciated.

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?

[Submitted as FB22200608] With Increase Contrast turned on, the selected row highlight in a List behaves inconsistently between light and dark appearance on iPad. In light appearance the blue selection highlight correctly becomes darker, but in dark appearance it becomes lighter instead. The text contrast ratio drops from about 3:1 to about 1.5:1, well below accessibility guidelines. This reproduces both in the simulator and on a physical device. The sample uses a standard SwiftUI List inside NavigationSplitView with built-in selection styling. No custom colors or styling are applied. REPRO STEPS Create a new Multiplatform project. Replace ContentView with code below. Build and run on iPad. Select an item in the list. Turn on Dark appearance (Cmd-Shift-A in Simulator). Turn on Increase Contrast (Cmd-Control-Shift-A in Simulator). Observe the selected row highlight. ACTUAL In light appearance, the blue selection highlight becomes darker when Increase Contrast is on, improving contrast as expected. In dark appearance, the blue selection highlight becomes lighter when Increase Contrast is on, reducing contrast between the selection background and the white text. EXPECTED Increase Contrast should consistently increase contrast. In dark appearance, the selection highlight should become darker—or otherwise increase contrast with the foreground text—not lighter. SAMPLE CODE struct ContentView: View { @State private var selection: String? var body: some View { NavigationSplitView { Text("Sidebar") } content: { List(selection: $selection) { Text("Item One") .tag("One") Text("Item Two") .tag("Two") } } detail: { if let selection { Text(selection) } else { Text("Select an item") } } } } SCREEN RECORDING CONTACTS The Contacts app behaves correctly. When Increase Contrast is turned on, the selection blue becomes darker, improving contrast. PASSWORDS The Passwords app, however, exhibits the issue. With Increase Contrast turned on, the selection blue becomes lighter instead of darker, reducing contrast.

Greetings! I'm facing a problem handleling full keyboard access in my app. This is a simpler version of the code: struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } .navigationTitle("Title n stuff") .padding() } } And the focus behaves as expected and the important thing, we can access que button on the right side of the screen But as soon as we introduce the scrollview, the right side button is unaccessible, since when we hit tab we go back to the back button in the nav stack header. struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { ScrollView { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } } .navigationTitle("Title n stuff") .padding() } } I've tried all the things I found online and none achieves an acceptable behavoir, I've seen ppl saying this issue has been fixed in ipados with the focusSection modifier, but I have not seen any fix fot this issue in ios.

I am currently trying to get my app ready for full external keyboard support, while testing I found an issue with the native DatePicker. Whenever I enter the DatePicker with an external keyboard it only jumps to the time picker and I am not able to move away from it. Arrow keys don't work, tab and control + tab only move me to the toolbar and back. This is how they look like private var datePicker: some View { DatePicker( "", selection: date, in: minDate..., displayedComponents: [.date] ) .fixedSize() .accessibilityIdentifier("\(datePickerLabel).DatePicker") } private var timePicker: some View { DatePicker( "", selection: date, in: minDate..., displayedComponents: [.hourAndMinute] ) .fixedSize() .accessibilityIdentifier("\(datePickerLabel).TimePicker") } private var datePickerLabelView: some View { Text(datePickerLabel.localizedString) .accessibilityIdentifier(datePickerLabel) } And we implement it like this in the view: HStack { datePickerLabelView Spacer() datePicker timePicker } Does anyone know how to fix this behavior? Is it our fault or is it the system? The issue comes up both in iOS 18 and 26.

Hi, I tried to sign up for the Developer Program 7 times, starting on January 5th. It's now been a month. I contacted customer support, they said to try enrolling through the Apple Developer App. I tried that, it asked me to do an identity verification, which I did, successfully. Then the "enroll" button on the app got grayed out and it says: "Enrollment through the Apple Developer app is not available for this Apple Account. Visit http:// developer.apple.com/programs/enroll/." I go to that link, I click "continue with your enrollment", I pay the $99, it goes through, I don't get charged anything, just a $0.00 authorization transaction, then get the "Order Acknowledgment" email, then nothing happens, it just goes nowhere. Please help. If there is anything I can do, or any more information I should supply for this to go through. I contacted support multiple times, but I don't get any response. My enrollment ID is DPTB3R8T2Z.

Hello everyone, I am currently evaluating my app's accessibility features to accurately display the "Accessibility" information on the App Store. I have encountered two specific issues regarding Voice Control testing and would appreciate any guidance. Voice Command for "Stop Recording" According to the evaluation criteria, if an app supports audio recording or dictation, users must be able to start and stop recording using only their voice. Behavior: I can successfully trigger the recording using the command "Start Recording". However, I cannot find a command to stop it. Commands like "Stop Recording" or "Stop" are not recognized by the system. Question: Is there a specific standard voice command intended for stopping a recording? Item Number Overlays on Non-Interactive Web Elements (WKWebView) I noticed an inconsistency between native views and web content regarding Voice Control item numbering. Behavior: When testing web content within the app (WKWebView) or in Safari, Voice Control displays item number overlays on non-interactive text elements (such as standard or tags). In native views, static labels do not receive item numbers. Question: Is this expected behavior for web content? Since these elements are not interactive, I am unsure if this should be considered a bug (fail) or an acceptable exception for the accessibility evaluation. Has anyone experienced similar issues or know the correct criteria for these cases? Thank you.

I started to use the Accessibility features of UIKit but cannot get the numbers or labels to show up on UICollectionCells. The image here shows a 3x3 matrix with no numbers, but the numbers on the menu commands show up. Actually these are just iOS accessibility features, not my app. I've tried reducing the size of my images or no images, but nothing shows up (in any of my UICollection code). I can get them to work on UITableView cells. I've tried the Accessibility selection in the storyboard or code, but nothing helps.

I have sent in a feedback report (FB18222398) but I have no idea if anyone has looked at it. I know from past experiences that Apple devs do look at these forums. This applies to each of the betas, 1, 2 and 3. I have created a new Personal Voice with each beta. I create a personal voice in English. When it's done processing, I tap Preview and it says in English what is expected. But after some time, an hour or a day, the language of the voice file changes languages and no longer works properly. If I press Preview it is no longer intelligible. I have a text to speech app and initially the created voice works but then when the language of the file changes, it no longer works. I have run an app on my iphone through Xcode that prints to the console the voices installed on the device with the language. Currently this is the voice file: Voice Identifier: com.apple.speech.personalvoice.AAA9C6F2-9125-475F-BA2F-22C63274991D Language: es-MX and on a second device the same personal voice is in a different language: Voice Identifier: com.apple.speech.personalvoice.AAA9C6F2-9125-475F-BA2F-22C63274991D Language: zh-CN Although, a previous personal voice file that listed as Spanish-Mexican played in English with a Spanish accent or when playing Spanish text, it sounded almost perfect. This current personal voice doesn't do that, and is unintelligible. Previous attempts have converted to Chinese. I hope someone can look into this.

I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears. I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.

Problem Safari requires tabindex="0" for keyboard access to scrollable containers. Chrome (v130+) and Firefox (v4+) handle this automatically. Current Behavior Chrome/Firefox: Scrollable div with overflow: auto → automatically keyboard-accessible (Tab to focus, Arrow keys to scroll) Safari: Same element → NOT keyboard-accessible unless: Add tabindex="0", OR Container has focusable children Workaround <div style="overflow-y: auto; height: 300px;" tabindex="0"> <!-- content --> </div> Issue: Adds unnecessary tab stops on Chrome/Firefox where not needed. Request Will Safari support auto-focus for scrollable containers? (matching Chrome/Firefox) If not planned: Any official Apple guide for cross-browser scrollable accessibility? Timeline? If on roadmap, estimated Safari version? Can I subscribe for updates? Use Cases Dropdown menus Modal dialogs Tab panels Data tables Chat interfaces Reference: WCAG 2.1 Keyboard Accessible: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html Example component: https://www.radix-ui.com/themes/docs/components/scroll-area

We have a password entry field with a "show password" button. The button effectively turns the "secure text entry" textfield into a non-secure text entry field allowing the user to view what they typed in. When VoiceOver is enabled, I am not including that button in the UI; it doesn't seem to make sense to me for the following reasons. If you properly test with the screen curtain, the functionality is useless. You don't see anything. I've tried to explain this to my accessibility team. It's also quite ridiculous to offer to show a blind user their password, I'm sure they'd love to see it, but they just can't. This would almost seem insulting as well. If by toggling that button, and turning a secure text entry into a non-secure text entry, now the app is literally speaking their password aloud. This seems like a security vulnerability to me. What if someone else overhears the password spoken aloud. The accessibility team is insisting that I need to include the "show password" button when VoiceOver is enabled. This is the response I received. "functionality should be the same for VI users as for sighted users. It may happen that a VI user wants to check what is typed into password field in order to correct mistakes". Again, I don't agree with that because functionality should not be the same. Functionality should be changed and altered as necessary to make the user experience as accessible as possible. And in this scenario, to me the functionality doesn't make sense at all in a VoiceOver setting. Any thoughts on this? Am I incorrect here? Are there benefits of including a "show password" button to a user utilizing VoiceOver? What should then the functionality be? Speak the password aloud? Thanks.

Hey, We've run into an issue where WKWebView contents are not always available for VoiceOver users. It seems to occur when WKWebView contents are loaded asynchronously. I have a sample project where this can be reproduced and a video showing the issue. See FB21257352 The only solution we currently see is forcing an update continuously using UIAccessibility.post(notification: .layoutChanged, argument: nil), but this is ofc a last resort as it may have other unintended side effects.

Hi everyone — I’m implementing the new Hearing Device Support API described here: https://developer.apple.com/documentation/accessibility/hearing-device-support I have MFi hearing aids paired and visible under Settings → Accessibility → Hearing Devices, and I’ve added the com.apple.developer.hearing.aid.app entitlement (and also tested with Wireless Accessory Configuration: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.external-accessory.wireless-configuration ). com.apple.developer.hearing.aid.app xxxxx but the app won't even compile with this entitlement Problem NotificationCenter.default.addObserver(...) for pairedUUIDsDidChangeNotification never fires — not on app launch, not after pairing/unpairing, and not after reconnecting the hearing aids. Because the notification never triggers, calls like: HearingDeviceSession.shared.pairedDevices always return an empty list. What I expected According to the docs, the notification should be posted whenever paired device UUIDs change, and the session should expose those devices — but nothing happens. Questions Does the hearing.aid.app entitlement require special approval from Apple beyond adding it to the entitlements file? Is there a way to verify that iOS is actually honoring this entitlement? Has anyone successfully received this notification on a real device? Any help or confirmation would be greatly appreciated.

Is the accessibility feature, voice command recording available on the Apple Vision Pro? It does not start on my device. The Apple Vision Pro is on 26.1. Regular single voice commands work on the Apple Vision Pro. Recording commands worked on other devices. (iPad and iPhone)