We are seeking guidance on the Apple-recommended way to handle aggregated accessibility labels in UIKit. When grouping elements into a single accessibility container, we need VoiceOver to read their labels with a natural structural pause, without injecting conversational grammar. SwiftUI handles this automatically and gracefully with .combine, but we need the endorsed UIKit equivalent for complex custom views. The Problem When manually aggregating child labels into a parent's accessibilityLabel in UIKit, VoiceOver behaves inconsistently in non-Latin scripts. For example, if we simply join the strings with a Latin comma (", "), VoiceOver ignores the separator in languages like Arabic or Japanese, reading the aggregated labels as a confusing run-on sentence. What we have considered and tried: NSListFormatter: While it correctly localizes separators, it inappropriately injects list grammar (e.g., adding "and" before the final item). Since our UI elements are merely spatially grouped on the screen and do not form a grammatical sentence, this confuses users. Hardcoded punctuation (e.g., Latin commas): Works fine for English, but fails to trigger VoiceOver pauses in non-Latin scripts as mentioned above. Double Line Break (\n\n): We found that joining strings with a double line break universally forces a hard stop and structural pause across all languages without injecting grammar. However, we have received community feedback suggesting that using newlines might cause poor formatting or UX issues on Braille displays. Our Questions: Is there an Apple-endorsed native approach to replicate SwiftUI's .combine behavior in UIKit that avoids injecting conversational grammar? If we must join the strings manually, is using a double line break (\n\n) considered safe and acceptable for Braille display users? Or is it better practice to manually map and apply localized commas? Any guidance from the Accessibility Technologies team or developers who have tackled this in large-scale UIKit apps would be greatly appreciated. Thank you!

For games that share a common codebase with multiple targets, what would be the recommended way to handle accessibility? For example an iOS game with a WatchOS companion that can played standalone. Any word how Voice Control will affect this combination? For iOS 26, I've had to handle some aspects of accessibility separately and needed to separate out some of shared codebase into each target.

I've found myself chasing my tail trying to programmatically adjust my .navigationTitle in SwiftUI so it doesn't get truncated given various dynamic type classes mixed with various device widths... Any guidance here on how to think about adjusting Ul copy based on AX type size constraints?

For example, our app uses an info icon in many places to open modals that explain useful terms or provide disclosures. For Voice Control it feels most natural to have users trigger it with a label like "info" as that matches the icon on-screen but for Voice Over "info" sometimes feels too vague and something like "Open terms to know" would provide more context. Is this just a good example of the use-case for accessibilityInputLabels so that we can have a more descriptive value for Voice Over and also provide a more natural label for Voice Control? Or should we re-think how to label these in a way that is consistent for both technologies?

I'm working on improving accessibility in a native macOS app and going through WCAG, but with so many success criteria it's hard to know where to focus for native Apple platform apps. 1. Does Apple recommend a specific subset or checklist of WCAG requirements for macOS and iOS? 2. If not, which criteria are generally considered essential, and how do developers typically validate them using Apple's accessibility tools and assistive technologies? I'm looking for a prioritized list of criteria that actually apply to native apps, rather than trying to implement every WCAG criterion individually.

When VoiceOver is enabled, it sometimes reads auto-generated image descriptions such as 'a blue and white logo on a white background' or 'warning icon, image error' instead of the custom accessibilityLabel we've set on the icons. How can we prevent VoiceOver from reading these image-specific descriptions and ensure it only reads our custom labels? Just like UIAccessibility.isVoiceOverRunning lets us check if VoiceOver is active, is there an equivalent API to detect whether Voice Control is currently enabled?

The existing API is roughly imported into Swift and pretty thorny. Some of this can be addressed with a wrapper library but some of it is much more difficult, like addressing AXObserver not having a finished event or callback to signify when it would be safe to do cleanup in a concurrent environment. A Swift overlay could be a great opportunity to make third part assistive tech more accessible.

Is it possible to use SSML to provide a VO string in multiple languages. For instance, a label in English, but you want it to speak a phrase within that sentence in Spanish for a proper noun.

When I try to inspect elements in the device hub, only the full window (group) is selectable. Am I doing it wrong? (FB22976268)

For example, we have a "card view" that navigates to a comprehensive detail screen... But there's an ellipsis on the card as well, that shows a menu of quick actions. We need both to be tappable. (SwiftUI project)

I have enabled "Voice Over" in the Device -> Accessibility Menu of the Device Hub, but I hear no Output. I was expecting Voice Over to be active when this option is selected. Running Xc 27 on MacOS 26.5. Do I maybe need to be on MacOS 27?

for example: Our designers want our "Disclosures/Legal" info icon, to be 4px from the text. So we end up needing to "hack" around the view, to make the info tap target exist "over" the text. without any hacks, if we use a 20x20 icon + 4 padding, the tap target is only 28px wide. the "hack" in question, usually involves adding paddings + inverted (negative) padding, to increase the tap target, without affecting layout

Can developers programmatically turn on Reduce (Liquid Glass) Transparency for their app? Or just for a view? Or will iOS 27 permit setting Reduce Transparency on an app-by-app basis?

Hello, In this press release from last month: https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ It indicates the following: "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." I have looked over the WWDC26 sessions but have not been able to find any information on this new API. Can you point me in the right direction? Thank you!

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!

I reported it to the beta team already but I was wondering if anybody else is not able to get there device to restart just by one tap using the AssistiveTouch menu?

I have enabled "Voice Over" in the Device -> Accessibility Menu of the Device Hub, but I hear no Output. I was expecting Voice Over to be active when this option is selected. Running Xc 27 on MacOS 26.5. Do I need to be on MacOS 27?

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.

I’m implementing an Apple AssistiveTouch eye tracker accessory for iPad over USB-C using iAP2 plus native HID Gaze Point reports. Current state: iAP2 authentication succeeds identification succeeds StartNativeHID is received AssistiveTouchInformation(IsEnabled=true) is received iPadOS enumerates the HID interface and consumes the interrupt IN reports The remaining issue is that the gaze-point behavior is not interpreted as direct screen coordinates. Repeated fixed gaze inputs produce deterministic but incorrect cursor motion, often appearing like orbiting or projection around a locus rather than stable placement. I have tested: the 119-byte Apple example HID descriptor from the Accessory Interface Specification two report-1 layouts: timestamp + x + y status + timestamp + x + y normalized and physical coordinate scaling verified on the wire that the intended report bytes are sent and consumed iPad console logs show internal model point (HID r) values and multiple derived Pointer positions for a single commanded point, which suggests the device is accepted but the gaze report semantics are still not what iPadOS expects. Questions: Is the example Gaze Point HID descriptor in the Apple Accessory Interface Specification sufficient as-is for iPadOS? What exact payload layout is expected for the Gaze Point report? Is a per-sample status byte required in the gaze input report? Are additional HID feature/input reports required for correct interpretation? I can provide: the exact HID descriptor bytes sample report payloads USB analyzer traces iPad console excerpts showing the resulting model-point and pointer projections

I am a quadriplegic. That means when I ask Siri something she comes back with an answer saying this is what I found on the web. This means nothing to me because I cannot use my fingers to pick up the phone. I I get a better and more detail from Alexa or Google nest. Go ahead and Google and or and Apple AI actually intelligent