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.

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.

So, in macos golden gate 27, there is this new live subtitles that happens in every video that i can't even turn off? (live captions is off) and also is there anyway from code we can turn this feature off, because making a background app, it exists whenever, and i can't seem to find a way to disable it from coding and the app.

I’m debugging a custom BLE HID device on iPhone. It is a composite HID mouse + keyboard dongle. Setup: Hardware: Seeed XIAO nRF52840 Firmware: Adafruit Bluefruit Arduino / BLEHidAdafruit BLE HID report map: stock Adafruit composite HID with keyboard, consumer, and mouse reports GAP/advertising appearance: HID_MOUSE iOS adopts the device as an AssistiveTouch pointer Mouse movement and clicks work correctly Keyboard symptom: Lowercase/unshifted characters type correctly. Shifted characters lose the Shift modifier during text input: - A -> a - T -> t - DoorDash -> doordash - ! -> 1 - @ -> 2 - # -> 3 - { -> [ - } -> ] Confirmed: The iOS app sends the exact intended string to the dongle. Firmware receives the exact string. Firmware computes and sends the expected HID modifier/keycode: A sends modifier 0x02 + HID_KEY_A ! sends modifier 0x02 + HID_KEY_1 A lone isolated "A" still lands as "a", so this does not appear to be a timing or repeated-key issue. Cmd+Space works from the same HID keyboard report path and opens Spotlight. Full Keyboard Access is off. Turning AssistiveTouch off does not fix it. The iPhone never shows "Hardware Keyboard" settings for this device, even when searching Settings. Question: Is there a documented distinction on iOS between accepting BLE HID keyboard reports for global shortcuts, such as Cmd+Space, and admitting the same device as a full Hardware Keyboard for text composition? In particular: Does the absence of Hardware Keyboard settings mean iOS has not classified the device as a real external keyboard? Can a composite BLE HID device advertised as HID_MOUSE be accepted for pointer input but have Shift ignored for text input? Does iOS require a different GAP appearance, HID report-map structure, report ordering, or separate keyboard identity for Shift/modifier text composition to work? Is there a recommended way to build a BLE HID device that preserves AssistiveTouch pointer behavior while also being treated as a full external keyboard?

[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") }

Since, Apple has long been recognized for its exceptional attention to typography. That is why I am surprised that Smart Punctuation in iOS does not respect national typographic conventions for quotation marks. For example, when writing in Czech, iOS automatically inserts English quotation marks (“…”) instead of the correct Czech form („…“), and there is currently no option to change this behavior. This may seem like a minor detail, but smartphones have become the primary writing tool for millions of people. As a result, the default option of the software does more than automate typing — it shapes writing habits. Or Even more, most users start assuming that automatically inserted punctuation is correct for their language. When iOS consistently uses English quotation marks in Czech text, it unintentionally contributes to the gradual disappearance of Czech typographic conventions. Even professionals often leave the default quotation marks unchanged because correcting them manually in everyday writing is impractical and slows down their writting. Typography is part of every language’s cultural identity. Localization should therefore include not only translated interfaces, but also language-specific typographic standards. Therefore, I would like to suggest that iOS should automatically use quotation marks according to the active keyboard language (or provide a setting to choose the quotation mark style). Czech users would receive „…“, French users « … », German users „…“ or »…« according to regional conventions, and so on. This small change would improve localization, respect linguistic diversity, history, and help preserve national typographic traditions. With the current implementation, Apple unintentionally contributes not only to the widespread use of incorrect writing, but also to the gradual erosion of national typographic traditions and language-specific writing conventions. Daniel

Hello, I would like to suggest adding dedicated keyboard shortcuts or menu commands for opening Notification Center and Control Center in both iOS Simulator and iPhone Mirroring. At the moment, these interfaces generally need to be opened by dragging downward from a specific area at the top of the simulated or mirrored iPhone screen. While this works for normal manual interaction, it is less reliable when using a mouse, especially when the window is resized or when the pointer needs to begin very close to the screen edge. This also creates difficulties for automated UI testing and computer-use agents, such as Codex-based testing workflows. These systems interact with the screen through mouse and keyboard input, so accurately reproducing an edge swipe can be unreliable. A small difference in the starting position may open Spotlight, scroll the current application, move the window, or fail to trigger the system interface entirely. It would be helpful if Apple could provide commands such as: Open Notification Center Open Control Center Dismiss Notification Center or Control Center These commands could be exposed through: Keyboard shortcuts The Simulator “Device” or “Features” menu The iPhone Mirroring toolbar or menu bar Accessibility or UI automation interfaces For example, Simulator already provides menu commands and shortcuts for actions such as pressing the Home button, locking the device, rotating the screen, and triggering other hardware-related interactions. Notification Center and Control Center could be handled in a similar way. This would improve: Manual testing with a mouse and keyboard Automated testing of applications that interact with notifications, media controls, Bluetooth, Focus modes, screen recording, and other system features Accessibility for users who have difficulty performing precise drag gestures Reliability for computer-use and vision-based testing agents Ideally, the commands should behave like genuine system gestures rather than directly changing internal state, so developers can test the complete user-visible interaction. Thank you for considering this feature.

Heya! is there anyway to allow a user to open an accessibility setting from an iOS app? As currently you kinda have to explain how to enable it on your device and honestly thats kinda completely against how accessibility ux should work as it as it requires and expects a user to read+understand something they might as well can't because of accessibility issues in the first place and thus basically punishing a user for it. I tested this with some users and asking them to go trough 3-5 menu's with overwhelming settings is to complex and most give up, thus directing them would solve that problem.

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. :🙏

We’re working on improving the accessibility of a MKMapView that displays custom MKAnnotationView instances. Our implementation is fully accessible with VoiceOver: The custom annotation views expose the correct accessibility information. Users can navigate between annotations using custom accessibility rotors. The overall VoiceOver experience works as expected. However, we’re unable to make the custom MKAnnotationView instances accessible through Full Keyboard Access (FKA). Despite configuring the annotation views as accessibility elements and experimenting with focus-related APIs, the annotations never become reachable through keyboard navigation. They appear to be skipped entirely by the FKA focus system. Is there a supported way to make custom MKAnnotationView instances participate in Full Keyboard Access navigation? If this scenario is currently unsupported, is there a recommended approach or any plans to expose public APIs that would allow developers to provide a keyboard-accessible experience for custom annotations in MKMapView? Any guidance would be greatly appreciated.

I'm building an iOS app in SwiftUI and need to adapt my UI when Voice Control is active — specifically to show labels on custom gesture-driven controls so they're accessible via Voice Control commands. I've checked UIAccessibility and can find notifications and properties for VoiceOver (isVoiceOverRunning), Switch Control (isSwitchControlRunning), and AssistiveTouch (isAssistiveTouchRunning), but I can't find any equivalent for Voice Control. UIAccessibility.isVoiceControlRunning and voiceControlStatusDidChangeNotification appear to exist on macOS (AXIsProcessTrustedWithOptions) but not on iOS. Questions: Is there a public iOS API to detect whether Voice Control is currently active — either a UIAccessibility property, notification, or SwiftUI environment value? If not, is the recommended approach to use UIAccessibility.isGuidedAccessEnabled as a proxy, or something else entirely? Is there a private entitlement or capability that unlocks this detection for App Store apps? What I've already tried: Checking AccessibilityFeatures environment values in SwiftUI (@Environment(.accessibilityReduceMotion) etc.) Thanks!

Experiencing an issue with UIContextualAction title text respecting the user's Dynamic Type / preferred content size category when Liquid Glass is active. It's setup using a UITableView with trailing swipe actions via trailingSwipeActionsConfigurationForRowAt. Under Liquid Glass, the contextual action buttons render as floating glass pills, but the title text within them remains at a fixed size regardless of the Dynamic Type setting. Increasing the preferred content size category to accessibility sizes has no visible effect on the action label font size. Any suggestions to make this scalable for dynamic font

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.

Hi, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

I find the inspector, file navigator, issue navigator, etc. all hard to read. Is there a way to increase the size of these texts without changing all of the text on my machine?

Hi, I want to detect if there is a fullscreen window on each screen. _AXUIElementGetWindow and kAXFullscreenAttribute methods work, but I have to be in a non-sandbox environment to use them. Is there any other way that also works? I don't think it's enough to judge if it's fullscreen by comparing the window size to the screen size, since it doesn't work on MacBook with notch, or the menu bar is set to 'auto-hide'. Thanks.

Hello Albert! I am experiencing some strange bugs around DeviceActivityEvents (part of the DeviceActivity framework) on iOS 26 / iOS 26.1 / iOS 26.2 beta: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold() is called. The property includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold() is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26 / iOS 26.1 / iOS 26.2 beta? Only workaround I have found is to ask users to revoke and re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed, so it is not a permanent solution unfortunately. Feedback (incl. sysdiagnoses and sample project) is filed under: FB18061981 FB18927456 One of our users has filed their own feedback request as well: FB20817853 Thanks a lot for any help on this!

User might be caught in a Guided Access page with error like this when they trying to leave Guided Access. Please pardon me for shotting a photo with phone to show this condition, because I can't even get a screenshot with home button and power key pressed together. I can't lock the screen with power key or by the magnet sensor, can't get back home page with home button. The ways to exit is waiting for the exit button might could use, or the screen shutdown, or enforce the device to shutdown. After exit the Guided Access without rebooting the system, the Guided Access would be freezed for minutes, noticing the Guided Access can't be used. In iPadOS 26, since, I can prove confidently, 26.5beta1 even earlier, could discover that issue. The problem could happen several times in a day. I have raised that issue since April 25th and the ID is FB22608734, which has more than 10 similar reports. To say something beyond the issue, actually I guessed that my device, iPad mini 5th, might can't get the update of iPadOS 27, so I hoped that Apple Developer Teams could at least fix those annoying problems. Actually there is a long list in Chinese with problems summarised by some Chinese User I waited for a long time for a miracle in WWDC 27. But that's a miracle.

Environment: Xcode 26.5, macOS Tahoe 26.5.1 (MacBook Pro, Apple M4 Max). As a blind developer working in Xcode with VoiceOver only, I'd like to report accessibility issues that make it hard to complete properly signed and entitled apps using VoiceOver alone. Issue: The "Signing & Capabilities" tab is not directly accessible. The "Signing & Capabilities" tab in the target editor is central to app configuration (team selection, capabilities, provisioning profiles), but there is no dedicated keyboard shortcut to reach it. The path requires many steps: Cmd+1 to focus the navigator, selecting the project file with the arrow keys, activating it with Return, switching to the central editor area, selecting the target, and finally locating the tab in the top bar. Specific VoiceOver problems: When the project file is activated with VoiceOver, focus often lands inside the inline rename field instead of opening the project editor as expected. The toolbar containing the editor tabs (General, Signing & Capabilities, Resource Tags, Info, Build Settings, Build Phases, Build Rules) cannot reliably be focused with VoiceOver, which prevents direct tab switching from the keyboard. Impact: A routine task such as adding a capability requires a long VoiceOver sequence that must be repeated on every visit, plus the cognitive load of remembering the exact tab order. Suggested improvements: Provide a direct keyboard shortcut for the "Signing & Capabilities" tab, and ideally for each target editor tab (for example Cmd+Option+1 through Cmd+Option+7). Ensure that activating the project file in the navigator opens the project editor by default; renaming should require an explicit second key press (Return on an already selected item, consistent with Finder). Ensure the editor tab bar can be reached and traversed with VoiceOver, for example via Tab or Ctrl+Tab.

On tvOS, third-party apps cannot read number key presses from a connected keyboard or remote (except inside a text field). There is also no HDMI-CEC API. Because of this, a live-TV / IPTV app cannot let the user simply type a channel number to change channels. This excludes a large group of users, especially older people. They have used numbered channels for their whole lives — they remember that a given number is a specific channel and just want to press that number to get there. It is the simplest and most familiar way for them to use a TV. Making them navigate an on-screen grid with the Siri Remote instead is much harder and unfamiliar for them. Please give apps a way to support numeric channel entry on tvOS — for example by letting apps receive number key presses (0–9) from a connected Bluetooth keyboard/keypad without forcing a text field, or by exposing the numeric keys from the TV's own remote via HDMI-CEC. Other TV platforms already pass number keys from the remote to apps, so this works for them today. tvOS does not, which leaves these users without a basic, expected way to use their TV.

Hi everyone, We're experiencing a bug on iOS 26 that only occurs when the user has Reduce Transparency enabled in Accessibility settings. App structure: Our app uses a TabView with a standard tab bar. Inside each tab, we use a NavigationStack. The tab bar is visible on root-level screens, and hidden on all pushed destinations using: .toolbar(.hidden, for: .tabBar) The problem: On iOS 26 with Reduce Transparency off (Liquid Glass active) — everything works correctly. The tab bar hides as expected. On iOS 26 with Reduce Transparency on — a white bar appears at the bottom of the screen in every place where the tab bar is hidden. This white bar: Overlaps content at the bottom of the screen. Blocks scroll, tap, and all user interactions in that area. We also tried: .toolbarBackground(.hidden, for: .tabBar) Removing all custom UITabBarAppearance configuration The only workaround we found is setting UIDesignRequiresCompatibility = YES in Info.plist, which reverts the entire app to the pre-iOS 26 design — not a viable long-term solution. What can we do? Thanks in advance.