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.

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?

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.

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?

Up to iOS 18 there were many voices available on device by default including "Nicky" that I use in my app. Somewhere around iOS 18.6 or 26.0 these voices were removed and no longer included in the OS by default. This broke my app that counted on the Nicky voice being available. My only workaround is to direct my users to download the voice again by going to Accessibility > VoiceOver > Speech > Voices and downloading "Nicky". I cannot simply switch to using Samantha (the only voice that is still available by default) because I have heavily customized how IPA pronunciations are tweaked to make Nicky speak Old English correctly. I tried briefly with Samantha but the results were not as good. I have 2 questions: Is there any way for me to include the "Nicky" voice in my app or for me to trigger the download from the app so I don't have to show an error and direct users through the settings app to get the voice? Are there any new features with AI voices in iOS 27 that I can use with IPA pronunciations to get them to speak possibly better than the Nicky voice? FB17834189

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

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!

Given the new Voice Control natural language enhancements, is there any change in guidance for how developers use accessibilitylnputLabels? Does providing robust utterance coverage across our views still help tune the new system's NLU?