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.

On macOS, when navigating backwards with Shift+Tab from a focusable descendant to its focusable parent container, browser keyboard focus moves correctly, but the VoiceOver cursor remains on the descendant. document.activeElement confirms that the parent container has received focus, and the browser displays its focus indicator. However, VoiceOver continues to announce and visually indicate the previously focused descendant. The issue is reproducible: in our web application; in Safari, Chrome, and Firefox; in the W3C ARIA APG Feed example: https://www.w3.org/WAI/ARIA/apg/patterns/feed/examples/feed-display.html The same navigation works correctly with NVDA on Windows: both keyboard focus and the screen reader cursor move to the parent. Expected result: When Shift+Tab moves keyboard focus to the parent container, the VoiceOver cursor should follow and announce that container. Actual result: Keyboard focus moves to the parent, but the VoiceOver cursor remains on the previously focused descendant. Environment: macOS 27.0.1 (26A434) Safari 27.0.1 Chrome 155.0.8059.80 Firefox 133.0 Reported through Feedback Assistant as FB25212861

Hello Apple Developer Community, I’m Yashwanth Pentakota, the independent developer behind EyeFlow, a prototype exploring hands-free screen navigation using a standard device camera. EyeFlow focuses on gaze-based scrolling and dwell-based selection. The goal is to support people who have difficulty using a mouse or touchscreen. My current work includes improving calibration, reducing gaze jitter, and preventing unintended actions. I’m exploring bringing this interaction model to Apple platforms and would appreciate guidance on one architectural question: For gaze-controlled scrolling and selection within my own app, which supported Apple frameworks or APIs should I evaluate first, and what platform limitations should I account for? My current pipeline is: Camera capture → face/eye detection → gaze estimation → calibration and smoothing → scrolling or selection. This is an experimental prototype; I’m still evaluating its accuracy and usability. Prototype/source: https://github.com/Yashwanth6121/Eye-Flow-v3. Suggestions on relevant documentation or sample projects would be helpful. Thank you, Yashwanth Pentakota

I'm using Dynamic Font throughout my entire app yet the audits in Accessibility Inspector will give me a ton of "Dynamic Type font sizes are unsupported: User will not be able to change the font size of this SwiftUI.AccessibilityNode" warnings. This is incorrect because users are able to change the font size. I can even move to the inspector panel and adjust the font and see it all change right within the Accessibility Inspector. I assume this is a bug since I can change the font but I was also wondering if there's some special thing I'm missing that could prevent these warnings from appearing especially when management runs audits to look for deficiencies.

When I toggle on VoiceOver in Device Hub, it looks very promising! But how can I emulate the gestures, double tap to activate, etc... Is this not possible? Right now I can just focus on different elements by clicking on them with the mouse. But, again, I can't activate anything, press button etc.

We are migrating our macOS applications from the legacy PPPC Accessibility service to the macOS 27 declarative App Settings configuration, as recommended by Apple. The applications require Accessibility permission to provide managed data-protection functionality and create the required event taps. Our configuration contains: A declarative com.apple.configuration.app.settings configuration that sets the Accessibility privacy permission to Allow. A legacy PPPC payload that grants PostEvent, because this service is not available through App Settings. The declaration and PPPC payload are delivered and applied successfully. After the user accepts the macOS Allow / Not Now prompt, the application’s Accessibility slider is enabled under: System Settings → Privacy & Security → Device Control and Data Access The user can turn it off even while the management declaration remains installed and active. When the user disables the setting: The application loses Accessibility access. Required event-tap functionality stops working. The application may display the legacy Open System Settings / Deny Accessibility prompt when the protected feature is subsequently activated. Manual user intervention is required to restore the application’s functionality. Expected behavior: We expected an Accessibility permission managed by MDM/DDM to remain enforced while its declaration is active, similar to the behavior of an Accessibility permission granted through the legacy PPPC payload. Apple’s AppSettings documentation states: “The user can change the app permission privacy settings in Settings.app if they choose.” This appears to describe the behavior we are observing. However, it is unclear how an organization can enforce a required Accessibility permission after the legacy PPPC Accessibility grant is deprecated on macOS 27.

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

We are experiencing an issue with Privacy Preferences Policy Control (PPPC) profiles deployed through Jamf Pro on the Golden Gate beta. We use the following Jamf configuration profiles to pre-approve Digital Guardian Accessibility permissions: DG – Grant Accessibility Access to DgSessionSvc.app DG – RME These profiles are intended to grant Accessibility permissions automatically for Digital Guardian under: System Settings → Privacy & Security → Accessibility On macOS Tahoe and macOS Sequoia, these PPPC profiles work as expected. After deployment, the required Accessibility permissions are granted automatically and users are not prompted. However, on the Golden Gate beta, the same configuration profiles are installed successfully, but the required Accessibility permissions are not granted. As a result, users continue to receive the Accessibility permission prompts. We also observed a difference when inspecting the installed profile under: System Settings → General → Device Management → Profile On macOS Tahoe, the installed profile contains the following entry: Control the Computer — com.verdasys.DgSessionSvc — Allowed On the Golden Gate beta, this entry is missing, even though the identical Jamf PPPC profile has been installed successfully. For reference, we have attached: The Jamf PPPC configuration profiles (.mobileconfig) DGSessionSvc MobileConfig RME MobileConfig Comparison screenshots from macOS Tahoe and the Golden Gate beta Could you please confirm whether this is: a known issue in the Golden Gate beta, an intentional change in PPPC behavior, or an issue with our PPPC configuration profile? If this is an operating system issue, we would appreciate it if it could be investigated and addressed in a future Golden Gate beta release. Environment Affected OS: Golden Gate 27.0 Beta (26A5388g) Working OS versions: macOS Tahoe and macOS Sequoia MDM Solution: Jamf Pro 11.30.1 Affected Application: Fortra Digital Guardian Required Permission: Accessibility (Control the Computer) Architecture: Apple silicon We would also appreciate it if you could review the attached .mobileconfig files and let us know whether any modifications are required to make the PPPC profiles compatible with the Golden Gate beta, or if any additional information would be helpful for your investigation.

PermissionDefaults under Privacy for com.apple.configuration.app.settings , device reports Info.UnsupportedSettings for "$.Privacy.PermissionDefaults for macOS 27 device iMac manufactured 2024 Request from MDM : "Type": "com.apple.configuration.app.settings", "Payload": { "Privacy": { "PermissionDefaults": { "net.soti.mobicontrol.macOS": { "OrganizationJustification": "Message", "Accessibility": "Allow" }, "net.soti.mobicontrol.macOSHelper": { "OrganizationJustification": "Message", "Accessibility": "Allow" } } } }, "Identifier": "2adc58b3-f631-41b8-93d8-f55612055c30", "ServerToken": "4dc895cc-b7c2-4729-b8a4-f9e2f8dba5a9" } Response from Device: { "StatusItems": { "management": { "declarations": { "activations": [ { "active": true, "identifier": "77409e31-ff4f-4f86-a1bd-175515e3a3bd", "valid": "valid", "server-token": "b096dd48-a127-4f65-a60d-bd615911deb8-1" }, { "active": true, "identifier": "84992e13-edc2-4791-989e-0cc54bd18ab8", "valid": "valid", "server-token": "8460aca3-b263-43fe-b659-343c81a6479e" }, { "active": true, "identifier": "bfd661e8-b81f-4383-b243-00330fca13ae", "valid": "valid", "server-token": "38399079-5402-401a-83f4-c39e8b4807e8" } ], "configurations": [ { "active": true, "identifier": "00d217fe-f6e2-479f-89b5-73b479bd9f1d", "valid": "valid", "server-token": "c25104a2-6d13-44a1-ac00-ccc916490ae9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "2adc58b3-f631-41b0-93d8-f55612055c30", "valid": "valid", "server-token": "4dc895cc-b7c2-4429-b8a4-f9e2f8dba5a9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "c5bc77f6-745d-43ae-9e49-6e9100d3f6a5", "valid": "valid", "server-token": "e3a5cdb3-fd51-42a2-afb4-fe5f602a493d-1" } ], "assets": [], "management": [] } } }, "Errors": [] }

Platform & OS Version: iOS 27 Screen Reader: VoiceOver Framework: SwiftUI / UIKit / WebKit (WKWebView) Issue Summary: When updating dynamic text or UI elements containing fraction values—whether using Unicode fraction glyphs (e.g., ½, ¾) VoiceOver in iOS 27 completely omits and skips reading the fraction value entirely. Steps to Reproduce: Enable VoiceOver on iOS 27 (Settings > Accessibility > VoiceOver). Open an app or web view where fraction values, tap to focus on the element or trigger voice over Expected Result: VoiceOver should speak the accessible label or text content (e.g., "one half") Actual Result: VoiceOver skips the fraction entirely, reading only surrounding text or remaining silent over the fraction value.

Update: I clarified the intended behavior after posting. The destination is the text input that has keyboard focus when the finished dictation is delivered, even if the user changed fields or apps while speaking. We do not need to return to the field where dictation started. I’m building a macOS dictation app for the Mac App Store, so it must run with App Sandbox enabled. For example, a user might start dictating with an input in Chrome focused, then click into a ChatGPT input while speaking. When the result is ready, it should insert at the ChatGPT caret. Moving the caret within one app should likewise change the destination. In an isolated signed sandboxed prototype, I write a marker to the general pasteboard and post Command–V with CGEvent.post after the user grants event-posting access. This inserts successfully in TextEdit at the current caret, including after a same-document caret move. That result is now consistent with the intended behavior. The prototype also has a frontmost-process guard that withholds insertion after an app switch; that is our own guard and could be removed. We have not yet verified cross-app delivery without it. The existing nonsandboxed app uses AXUIElement to inspect the focused field. Apple’s App Sandbox documentation lists assistive Accessibility APIs as incompatible with sandboxed apps. For a current-focus insertion design, is there any supported sandbox-compatible way to know whether the destination has a focused editable field or is a secure input, or to learn whether a posted paste was actually accepted? If not, is relying on the destination app’s paste handling and retaining the transcript for manual recovery the expected approach? I also tested an AppKit Service. TextEdit inserts its returned text when the caret stays put; after a physical click to another caret during a pending request, the provider returns but TextEdit inserts nothing. This does not appear to fit our hold-to-dictate, switch-apps-while-speaking interaction. I’d welcome experience with another system-mediated approach that does. Environment: macOS 27.0, Xcode 27.0, Apple Silicon. I’m asking about technical API behavior and implementation patterns, not a guarantee of App Review approval.

We're designing a two-person layout for iPhone Duo. The device lies fully open and flat on a table between two people facing each other. The inner display is in portrait orientation and split with ArrangementView using the default .split style, which stacks the regions in a tall window. Each person gets the half nearest them, and the far region uses .rotationEffect(.degrees(180)) so it faces the second person. The hinge isn't used for layout. While iPhone Duo lies fully open and face-up, does the interface orientation stay stable if the device is nudged or turned on the table? Is there a recommended way to hold it steady for one screen without restricting orientation app-wide? Is rotating one arrangement region 180° a supported pattern? Specifically, do the reserved regions from GeometryProxy.reservedRegions(kind:options:) need to be converted into the rotated region's coordinate space by hand? And do VoiceOver hit-testing and the focus ring follow the rotation? In an immersive full-screen view in this posture, can the status bar be hidden? If not, what's the recommended handling of its occlusion region, which would appear upside down to the second person?

I am unable to dismiss Voice Control Siri AI bubble when enabling Voice Control in iOS 27. Can someone from accessibility team provide guidance on how to dismiss without touching the screen in the activation flow? Siri bubble remains on screen... Thank you, and appreciate all the work you do. Voice Control is an amazing capability system wide.

I'm building an accessibility feature where a user walks around and taps NFC tags to trigger updates in the app (e.g., wayfinding/context info). I want a "Live Mode" toggle that keeps the app listening for NFC reads continuously while it's on, processing each tag as it's scanned, rather than one-shot read-and-dismiss. Is there a Core NFC API or session configuration that supports this kind of continuous/persistent listening, or does every read still require invalidating and restarting the session afterward? Currently: I have high-performant reads working reliably with passive NDEF/tag detection. What I'm trying to figure out: Recommended approach — should I keep a single long-lived NFCReaderSession alive and handle repeated reads within it, or restart a new session immediately after each read? VoiceOver / accessibility — how does the system NFC sheet interact with VoiceOver, especially if the session is restarting frequently while the user is mid-walk? Session timeout and restart handling — what's the best way to detect and recover from a session timing out or invalidating unexpectedly, without the user noticing a gap in "Live Mode"? Battery/radio use — are there known concerns with keeping NFC polling active over an extended period (minutes, not seconds)? Thank you.

Hello everyone, I am the developer of a macOS window management app called NeoTiler. I am currently optimizing it entirely for Apple Silicon using Swift. I am using the Accessibility API (AXUIElementSetAttributeValue) to resize windows. While it works flawlessly on Safari and native apps, I've noticed a slight animation stutter when resizing Electron-based apps like VS Code or Discord. Has anyone experienced this specific stutter with AX APIs on M-series chips? Are there any workaround flags I should pass? Thanks!

Hi 👋, I’m working on improving Full Keyboard Access support in an iOS app and would love to hear about your experience. When developing for keyboard navigation, what approach do you usually take for navigating between UI elements? Do you mainly use Tab/Ctrl+Tab, arrow keys, or a combination of both? I’ve already watched some WWDC sessions and Apple's docs on this topic: https://developer.apple.com/design/human-interface-guidelines/keyboards https://developer.apple.com/videos/play/wwdc2021/10120/ https://developer.apple.com/videos/play/wwdc2021/10260/ https://developer.apple.com/documentation/UIKit/navigating-an-app-s-user-interface-using-a-keyboard However, I’d appreciate any recommendations for useful resources, documentation, or things to be aware of when implementing keyboard accessibility. :🙏

I’m having an annoying floating keyboard bug on my iPad Pro M4 using ipados27, it won’t let me move the keyboard all the way down or up the screen it’s like it’s stuck within a 16:9 letter box. It seems to sometimes work on the Home Screen and let me move it down all the way but if I go to the app screen or any app and use the keyboard it will spring it back up and won’t go back in the place I want it. I also noticed that there is no animation for the keyboard being dismissed as well. It simply will disappear within a split second. It’s very janky as even when I pull up the keyboard while in a windowed app that allows my home bar to show, the keyboard will cause the home bar to be hidden away even though the keyboard won’t even hover on the location of where the home bar is. It just hides it away, it seems that the region its allowed and where it’s detected within the system is being misinterpreted. The disappearing bug is newer it started on ipados27 but the restrictive keyboard has been an issue since like iPadOS 17 or 18. Another bug I’ve had for years is the virtual trackpad feature that’s inside the touch accommodations accessibility options. This feature is only on the iPad sadly, but I would find or think that it would be super useful especially when I have a secondary monitor attached to the iPad but it refuses to work at all when another monitor is connected. Not that it works without another monitor attached. It is completely unusable as it doesn’t scroll and gets stuck, the windowing management for the app I have open gets priory over my interactions on the trackpad leading to me resizing the window instead of the trackpad moving the mouse if I click on a corner too far. All in all it’s a completely useless feature and I have tried everything in the book to fix it myself and even report the issue but this has been broken since I got my first iPad. Please try the feature out and see what I mean, nothing works other than moving the old version of the mouse cursor, no scrolling, no right clicking, and of course no gestures including 3/4 finger app switching or pinching in or out to zoom or two finger slide.

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.

Is there a way to simulate Display Zoom settings under the Appearance tab in Settings on a device simulator? I can only find this setting in my real device.

We are seeing a reproducible system-wide input hang when Accessibility permission is revoked from an application that has an active Quartz event tap. The behavior reproduces on macOS Sequoia, Tahoe, and Golden Gate. I have created the standalone diagnostic app(EventTapPassThroughTest) isolates an active Quartz event tap implementation. It creates a session-level event tap for keyboard and mouse events and returns every event unchanged. It does not register for Accessibility-change notifications, suppress events, recreate the tap, or re-enable a tap disabled by macOS. It contains only the following behavior: Requests Accessibility access using AXIsProcessTrustedWithOptions. Creates a session-level, head-insert CGEventTap with .defaultTap. Observes common keyboard and mouse event types. Returns every received CGEvent unchanged with Unmanaged.passUnretained(event). Adds the tap to the main run loop and enables it. It does not suppress or modify events. It does not register for Accessibility-change notifications, recreate the tap, or re-enable a tap disabled by macOS. In both the disable and delete cases, local keyboard and mouse input become unresponsive. A forced restart is required when no remote session is available. The result reproduces even though the event-tap callback always returns the event unchanged. We did not observe a tapDisabledByTimeout or tapDisabledByUserInput callback before input became unresponsive. System logs show TCC modifying or deleting the Accessibility record. WindowServer then checks the running application's kTCCServicePostEvent/kTCCServiceListenEvent access and receives a denied or unknown result. Input subsequently stops being delivered normally. Expected result Revoking the permission should invalidate or disable the application's event tap without affecting system-wide input. If the application is expected to perform cleanup, it should receive a documented notification or tap-disabled callback early enough to disable and invalidate the tap safely. Questions Is revoking Accessibility permission while an active .defaultTap event tap exists expected to be supported? Is there a documented notification that an application can observe before or when its Accessibility/PostEvent access is revoked? Is there a supported way to ensure an existing event tap is safely disabled when the user turns off or deletes the application's permission? Should WindowServer automatically invalidate the tap in this situation?

Using accessibilityRotor(_:entries:) as described in the documentation works fine on Xcode 26 and iOS 26 whereas it fails to compile on Xcode 27 when at least iOS 26 is selected as the minimum deployment target. .accessibilityElement(children: .contain) .accessibilityRotor("VIPs") { // ❗️Conformance of 'Optional<Wrapped>' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer ForEach(messages) { message in // If the Message is from a VIP, make a Rotor entry for it. if message.isVIP { AccessibilityRotorEntry(message.subject, id: message.id) } } } The error states "Conformance of 'Optional' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer" which should not be the case as the code was compiling prior to Xcode and iOS 27. Feedback is FB24587642. It contains a sample project to reproduce the issue. Using Xcode 27 beta 6 with iOS 26 as minimum deployment target and Swift 6 language mode.