Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing Associated Feedback Feedback Assistant Ticket: FB23666342 1. The Core Proposal On behalf of the assistive technology and screen-reader community, I am requesting the native system-level integration of the comprehensive Acapela Voice Library into iOS and macOS. This library should be added as a native synthesizer tier alongside existing options like Eloquence. Additionally, we request cross-pipeline voice compatibility, allowing the Siri assistant to utilize configured VoiceOver voice assets, and allowing VoiceOver to utilize Expressive Siri neural models. 2. Structural UI Layout Concept To maintain system cleanliness while maximizing user choice, we propose grouping the Acapela catalog exactly like the current native Eloquence implementation: A main, expandable heading titled Acapela inside the Speech rotor settings. Under this heading, voices should be strictly categorized by global regional dialects (including English U.S., English UK, Australia, India, Scotland, and all other languages offered to AT vendors). This deployment must include all specialized character profiles (such as the Little Creature variant) and their pediatric/child voices catalog. 3. Addressing Ear Fatigue and Equity While parametric synthesizers are excellent for high-speed text scanning, extended multi-hour document audits cause severe cognitive ear fatigue due to compressed, robotic waveforms. Integrating the full Acapela catalog—including both 22kHz HQ (High Quality) profiles for natural reading stamina and 22kHz CO (Colibri/Compact) profiles for rapid responsiveness—allows blind and low-vision power users to pick their preferred acoustic texture. Natively licensing this library eliminates the unfair financial barrier of third-party lifetime licensing fees, creating true out-of-the-box system equity. If you want to check out my post on expressive Siri, see below. Link: https://developer.apple.com/forums/thread/834920

Hi everyone, With the initial rollout of the iOS 27 Beta, the advanced configuration sliders for the new, highly expressive Siri voice models are currently hidden/disabled on devices operating under an 8GB RAM threshold. While the local AFM 3 Core Advanced engine is memory-gated to 12GB+ hardware due to local footprint constraints, this creates a significant barrier for users who rely on next-generation vocal expressivity and fluid dictation features for accessibility. To address this, I have filed a formal feature request (FB23178983) asking Apple to route the expressive Siri framework through Private Cloud Compute (PCC) on 8GB devices (like the iPhone 15 Pro or base iPhone 16 models). By utilizing server-side rendering over secure, stateless cloud nodes, Apple could easily deliver these vital accessibility configurations without exhausting the local 8GB memory footprint. I’m curious if other accessibility testers and auditors on this board are looking for this exact routing path? If you or your users rely on advanced speech synthesis features and are currently locked out by the local RAM gate, please consider filing a duplicate request or adding your diagnostic logs to FB23178983 to help increase visibility with the Core Accessibility and Software Architecture triage teams. Looking forward to hearing your thoughts and experiences with the current voice-indexing behaviors on 8GB hardware!

Hi, guys, so some apps needed accessibility in order to do some things on my mac, (macos 27) yet the tab has disappeared from my privacy and security tab?

Feedback Assistant ID: FB24788469 (Cross-reference: Complementary to third-party TTS framework initiatives logged in FB23666342) Overview With the continued evolution of on-device machine learning and Apple Silicon's unified memory architecture, I propose that Apple evaluate expanding the native VoiceOver speech library in the upcoming iOS 28 cycle to incorporate lightweight, natural acoustic and neural voice models—specifically the profiles utilized across ChromeOS, Android, and CNET accessibility pipelines (including the natural Google Assistant voice profile). Hardware Feasibility & RAM Footprint • Demonstrated Efficiency on 8GB Systems: In real-world desktop testing across both an ASUS laptop and an HP laptop configured with 8GB of RAM, these voice profiles operate with near-instantaneous responsiveness, zero audio stutter, and negligible memory overhead. • Client-Side Execution Proof: In testing with NonVisual Desktop Access (NVDA)—an open-source Windows screen reader for blind and vision-impaired users—these voices run client-side using Google's WebAssembly (WASM) text-to-speech engine via background Chromium runtimes. Even during heavy UI tree navigation and multitasking, the 8GB systems run effortlessly without memory pressure warnings, UI latency, or process termination. • Viability Across 8GB & 12GB Apple Silicon: Apple Silicon devices leverage high-bandwidth unified memory and dedicated Neural Engine cores. Compiling or running these lightweight neural acoustic models via Core ML on all 8GB and 12GB devices running iOS 28—as well as future hardware generations—leaves substantial headroom for foreground apps without risking memory eviction. Technical & Practical Justification 1. Prosody and Auditory Fatigue: Modern neural synthesis captures natural cadence, warmth, and contextual phrasing, substantially reducing listening fatigue during multi-hour screen reading sessions compared to older formant or diphone synthesizers. 2. Deterministic On-Device Latency (Sub-50ms): Screen reader users require immediate auditory feedback when navigating character-by-character or word-by-word. Running these models locally on-device guarantees the sub-50ms response times essential for VoiceOver, with zero network latency and complete offline reliability. 3. Cross-Platform Continuity & Inter-Platform Synergy: Blind and low-vision users who switch between desktop environments (such as Windows with NVDA or ChromeOS) and iOS benefit greatly from vocal consistency across their workflows. Furthermore, given Apple's established collaboration with Google regarding foundational AI models, exploring speech asset licensing or compiling these lightweight voice packages into native iOS speech audio units represents a logical, accessible extension of existing synergy. Proposed Solution Provide downloadable, on-device voice packages for these high-efficiency neural and ChromeOS-style profiles directly within: Settings > Accessibility > VoiceOver > Speech > Voice in iOS 28. It would be greatly appreciated if I could get community feedback. If posting in a language other than English, I'll use Gemini to translate it into English and post the translation for English speakers as a reply to this post. Also, if you want to check out my posts on Acapela's voice library integration, and my Expressive Siri posts, check out the links below and give me your thoughts on them as well. This post will be cross-linked on those as well, creating a closed triangular circuit. Expressive Siri Link: https://developer.apple.com/forums/thread/834920 Acapela Voice Library Integration Link: https://developer.apple.com/forums/thread/837701

header 1 於無障礙旁白功能使用上，存在數項可優化項目。 第一，旁白內「偵測語言」開關關閉後，部分文字與符號會出現無法朗讀的情況，系統已設定繁體中文、簡體中文，問題仍然存在。此現象在iOS 26之前的版本並未發生。 第二，旁白朗讀功能有時會失效、沒有聲音，必須關閉旁白再重新啟用，才能恢復正常。 第三，旁白詳細程度設定中，雖已關閉新手提示，仍然會出現大量多餘播報內容。另外在輔助快取模式之下，部分旁白手勢無法正常運作，最常用由底部向上滑動返回主螢幕的手勢會失效。 懇請開發團隊優化中文介面旁白多餘播報內容，在已關閉新手提示的前提下，讓旁白播報更加清爽簡潔，並修復上述各項狀況。

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 seeing a layout issue in SwiftUI on iOS 26 that only reproduces with specific Accessibility Motion settings. Steps to reproduce 1. Open Settings → Accessibility → Motion. 2. Enable Reduce Motion and Prefer Cross-Fade Transitions. 3. Launch an app with a SwiftUI TextField. 4. Tap the field to show the keyboard. 5. Dismiss the keyboard (tap outside, swipe down, etc.). Expected: After the keyboard is dismissed, the view’s bottom safe area / layout should return to normal. Actual: The view continues to reserve space equal to the keyboard height — as if the keyboard were still visible. UI anchored to the safe area remains shifted upward until the view is reloaded.

We format times in a localized way using the DateFormatter APIs.DateFormatter.localizedString(from: date, dateStyle: .none, timeStyle: .short)However if the result of this localization is say "22:00" VoiceOver just reads this out as "22". The VoiceOver user is given no indication that this numeric value is a time of the day.I've read online that one approach is to use DateComponentsFormatter and the spellOut unitsStyle e.g.let hourComponents = Calendar.current.dateComponents([.hour, .minute], from: date) cell.accessibilityLabel = DateComponentsFormatter.localizedString(from: hourComponents, unitsStyle: .spellOut)But again for a time "22:00" this reads out "22 hours". Sure if gives more context that this is related to time but it doesn't really indicate it is a time of the day i.e. it could be an interval (22 hours until something happens).We've trawled through the Apple documenation but we can't find anything that covers this.The best possible workaround we've found would be to force the accessibility label to be read out in 12 hour time i.e.let dateFormatter = DateFormatter() dateFormatter.setLocalizedDateFormatFromTemplate("hh:mm") accessibilityLabel =dateFormatter.string(from: date)that way it is clear to the user that it is a time of the day. Although this approach has the downside that ignores the user's preference of a 24 hour or 12 hour time display.The VoiceOver readout is handled perfectly in the Calendar app. It reads out "10 o'clock" and "22 hundred hours" in English and it is fully localized so for example it reads out "midi" for 12:00pm in French. It is possible that this is being done with private APIs though.So my question is, what is the recommended approach for formatting times for VoiceOver?

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.

To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa

I’m encountering what appears to be a synchronization issue between the numbers displayed by the iOS Voice Control overlay and the targets Voice Control actually activates. Environment: iPhone 13 Pro Max iOS 26.6.1 React Native 0.86.3 Expo SDK 57.0.17 Fabric/New Architecture enabled The issue occurs on a tutorial screen containing several interactive elements. After the screen changes or elements become enabled, disabled, mounted, or unmounted, Voice Control displays numbered overlays that do not correspond to its current command mapping. For example: Enable Voice Control and say “Show numbers.” Navigate to the affected tutorial step. The visible overlay places number 5 on an interactive square. Say “Tap 5.” Instead of activating that square, Voice Control activates the “Skip Tutorial” button. If I say “Hide numbers” followed by “Show numbers,” the newly displayed numbers reflect the actual command mapping. This demonstrates that: Voice Control’s internal target mapping has updated correctly. The visible number overlay has retained an older mapping. Saying a displayed number can therefore activate a completely different control. The behavior is reproducible in an older build that predates our Voice Control-specific tutorial changes, so it does not appear to have been caused by those changes. Setting the Voice Control overlay to “None” also does not resolve the underlying synchronization issue. I found a nearly identical cross-framework report in Flutter: https://github.com/flutter/flutter/issues/183821 That report describes the number overlay showing one mapping after button enabled-state changes while “Tap N” uses a different mapping. It remains open and does not appear to have a published workaround. Questions: Is this a known iOS Voice Control issue? Is there a supported way for an app to notify Voice Control that it must recalculate and redraw its numbered overlay? Would posting a UIAccessibility layout- or screen-changed notification help, or does Voice Control maintain this overlay independently? Are there particular patterns involving enabled/disabled or dynamically mounted accessibility elements that applications should avoid? Is there any way for an application to inspect the target associated with a Voice Control overlay number? My understanding is that these numbers are not exposed through a public API. This issue is especially concerning because the visible overlay instructs the user to say a number that can activate an unrelated control. In this example, it can activate “Skip Tutorial.” I can provide screen recordings and a minimal reproduction if helpful.

I would like to see an option to show live caption subtitles on Apple TV. So if I watch DAZN Sports it should generate subtitles via AI with settings enabled. This would give deaf people ability to watch sport with subtitles even it is not supported.

OK hello Apple developers, and whoever else is reading, I am a quadriplegic. This means I cannot use my fingers. So therefore I cannot pick up the phone. That means I cannot pick up the phone for Face ID which is biometric, fingerprint which is biometric, I believe the eye is biometric. So is the voice. That is how I have to login to my brokerage firms multiple bank account. Anything super secure I can use my voice as a password. It's super simple. Just add and the code and write it so therefore it is as simple as saying something to the effect of "hey seri my voice is my password. A few simple lines of code written by Apple expert this should not be hard at all and should be included in an update. Just think how would you use your phone if you could not pick it up. I cannot put Apple Pay i cannot secure on my phone because I cannot lock it because I cannot pick it up. Any help would be greatly appreciated

So using the developer website in Safari....produces this. How? How is this even possible? I know.... they used Chrome to test and develop with... ;) I am on the latest Safari. Sad.

We are seeing a hard main-thread abort on iOS 26 during cold launch when VoiceOver (or another accessibility client) is active. about 1–7 seconds after process start. The crashing thread essentially shows only main from the app; the fatal path is entirely in system frameworks. What happens is that UIAccessibility asks for an accessibility value, UIKit.axbundle handles it (on iOS 26.5 we exact-match-symbolicate this to -[_UITabButtonAccessibility accessibilityValue] + 120), then AXCoreUtilities safeSwiftValueForKey reflects a Swift object via Mirror / AttributeGraph. While copying an unowned field, the referent is already gone, so libswiftCore calls swift_abortRetainUnowned and the process dies. Not finding unowned in app source does not contradict this: the reflected object can live in system or SDK Swift state. OS versions in the corpus: iOS 26.5 (23F77), 26.6 (23G71), and 26.6.1 (23G83). All reports load UIKit.axbundle. Launch-to-crash gaps range from roughly 1.4s to 7.3s. Most 26.6 samples share UIKit.axbundle binary UUID 387c6473…; we did not have matching Device Support for that build locally. One iOS 26.5 sample has UIKit.axbundle binary UUID dca69975… and AXCoreUtilities 78a7c163…, both exactly matching local Device Support, so atos on that sample is trustworthy. On that iOS 26.5 sample (filename redacted), the symbolicated path is: VoiceOver / AX → UIAccessibility (_iosAccessibilityAttributeValue → _accessibilityAXAttributedValue → _accessibilityPotentiallyAttributedValueForNonAttributedSelector) → UIKit.axbundle -[_UITabButtonAccessibility accessibilityValue] + 120 → AXCoreUtilities (_AXSafeSwiftValueForKeyTm → safeSwiftValueForKey → _visitValueWithReflection) → AttributeGraph (AGTypeApplyFields2::Visitor::visit_field) → libswiftCore (swift_reflectionMirror_subscript → copyUnownedFieldContents → swift_unknownObjectUnownedLoadStrong → swift_abortRetainUnowned) → App: main only Frame 32 math: runtime 0x2be49b130, slide base 0x2be3cf000, offset 0xCC130 → _UITabButtonAccessibility accessibilityValue + 120. Questions for anyone hitting the same stack: 1.Is there already an Apple Feedback / radar for safeSwiftValueForKey + swift_abortRetainUnowned on iOS 26? crash_ios265_redacted.txt

We are testing the new Declarative Device Management (DDM) App Settings configuration on macOS 27 Golden Gate to manage Accessibility permission for our applications as suggested by the apple team in https://developer.apple.com/forums/thread/839536. We created a Jamf Blueprint with a custom com.apple.configuration.app.settings declaration and configured the required Accessibility settings. After applying the Blueprint to the User channel, we now receive the consent prompt shown in the attached screenshot. However, the permission flow does not appear to work as expected. Our understanding is that, after the user clicks Allow in this consent prompt, the configured Accessibility permission should be applied to the application without requiring an additional Accessibility authorization prompt. Instead, after selecting Allow, we still receive the subsequent prompt, which asks the user to choose either Open System Settings or Deny. The DDM declaration appears to have been successfully deployed and is shown as active on the system. Could you please clarify the following? Expected consent behavior: After the user selects Allow in the DDM App Settings consent prompt, should the configured Accessibility permission become effective without any additional Accessibility prompts? Consent scope: We are observing an Allow / Not Allow consent prompt for each DDM App Settings declaration. Is user consent expected to be requested separately for each declaration, or should macOS consolidate the Accessibility settings from multiple declarations into a single consent request? Additional Accessibility prompt: Why does the application continue to receive the Accessibility permission alert with Open System Settings / Deny even after the user has selected Allow for the DDM declaration? User interaction: Is there any supported way for an organization to manage or suppress these additional prompts so that no further user interaction is required after the initial DDM consent? Our goal is to understand the expected macOS 27 behavior and determine the supported management configuration for applications that previously received Accessibility permission through the PPPC payload.

Our app is being killed by the watchdog on iPadOS 26 (iPad Pro 11, 3rd gen) when navigating between tabs after using search. The crash only occurs when AssistiveTouch is enabled — disabling it prevents the issue entirely. The crash stack shows the main thread blocked in CoreUI vector glyph rasterization (CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition:) triggered during a UINavigationController transition while the keyboard is being dismissed: UINavigationController _startCustomTransition → UIKeyboardSceneDelegate _restoreInputViewsWithId → UITextField resignFirstResponder → SwiftUI ViewGraphRootValueUpdater.render → UIButton layoutSubviews → UIImageView _setImage → CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition: The termination reason: FRONTBOARD domain:10 code:0x8BADF00D "Failed to terminate gracefully after 5.0s" WatchdogEvent: process-exit WatchdogVisibility: Foreground Key observations: Only reproduces with AssistiveTouch enabled iPad Pro 11 (3rd gen), iPadOS 26 Our code is not on the crashing thread — it's entirely UIKit/CoreUI/SwiftUI framework code Similar to issues reported in thread/808808 (https://developer.apple.com/forums/thread/808808) and dotnet/maui#32365 (https://github.com/dotnet/maui/issues/32365) Is this a known issue with AssistiveTouch + UINavigationController transitions on iPadOS 26? Is there a recommended workaround?

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!

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?