I am investigating Accessibility Inspector/XCTest audit results in a SwiftUI app (Target Keeper), without suppressing warnings. Environment: Xcode 27.1 (27A9275), iPadOS 27.0 Simulator, macOS 27.0.1. Debug and Release builds pass. The app uses scalable text and labeled controls. Element Detection / native sheet Main-screen Element Detection passes when the sheet is closed. With a SwiftUI .sheet presented, the iPad audit reports “Potentially inaccessible text”; XCUIAccessibilityAuditIssue.element is nil. Exported Inspector HTML highlights background labels behind/outside the sheet, rather than a foreground control. The separate, data-free SwiftUI application below reproduces the modal-only warning; it links no application modules or persistence. Actual iPad Simulator VoiceOver testing using XCUIDevice.shared.voiceOverService passes forward/backward traversal of the real application's modal controls, without reaching the background labels. This is simulator evidence, not physical-device acceptance. A trial explicit modal container/.isModal trait did not clear the audit and was reverted; no warnings are filtered. Minimal independent app: import SwiftUI @main struct ModalRepro: App { @State private var showing=false private let names=["Vegetables","Protein","Fruit","Dairy","Grains","Healthy Fats"] var body:some Scene {WindowGroup { NavigationStack { VStack(spacing:24) { Button("Nutrition") {}.accessibilityLabel("Choose Page").accessibilityValue("Nutrition") LazyVGrid(columns:[GridItem(.flexible()),GridItem(.flexible()),GridItem(.flexible())],spacing:40) { ForEach(names,id:\.self) { name in Button {} label: { VStack(spacing:10) { Circle().fill(.blue.opacity(0.3)).frame(width:250,height:250) Text(name).font(.system(size:17)).accessibilityHidden(true) } }.buttonStyle(.plain).accessibilityLabel(name) } } Button("Show modal") {showing=true} }.padding(24).frame(maxWidth:.infinity,maxHeight:.infinity).background(Color.black) }.preferredColorScheme(.dark) .sheet(isPresented:$showing) { NavigationStack { VStack {Text("Foreground content");Button("Close") {showing=false}} .frame(maxWidth:.infinity,maxHeight:.infinity).background(Color.black) .navigationTitle("Modal flow") }.preferredColorScheme(.dark) } }} }In an Xcode UI-test target, launch this app, run try app.performAccessibilityAudit(for: [.elementDetection]), tap “Show modal”, then run the same audit again. The first passes and the second fails. No issue handler ignores failures. Contrast / scrolling — separate unresolved finding All four iPhone combined-audit configurations (portrait/landscape, normal/maximum Dynamic Type) pass in the tested picker state. However, iPad maximum-text combined audits and a separate scrolled iPhone maximum-text landscape contrast audit still fail; we are not calling these resolved. In the scrolled iPhone case, XCTest identifies a count label whose frame is entirely above the visible results viewport. Inspector's exported HTML reports 1.37:1 using #252526 versus #000000; its marked screenshot rectangle overlaps the dark search/header area, not visible count text. Visible sampled labels instead have white or light foregrounds on opaque dark fills (e.g. #FFFFFF/#1C1C1E = 17.01:1; #98989F/#1C1C1E = 5.94:1). These are screenshot core-pixel measurements, not proof every warning is false. We compare ordinary text against 4.5:1 and interactive non-text against 3:1. iPad maximum-text warnings have not yet been matched to an exact visible color pair. Original failures and HTML exports are preserved privately. Questions Is Element Detection expected to inspect background elements behind a presented native SwiftUI sheet? Is this a known tool limitation/framework issue, or does the sample need different semantics? What is the supported way to establish modal accessibility boundaries with SwiftUI sheets, and when should .isModal be added explicitly? How should we distinguish a real contrast defect from clipping, occlusion, translucency, or sampling of an offscreen element? Which Inspector export fields/diagnostics should establish the actual sampled text/background pair? What additional evidence/manual and physical-device tests does Apple recommend before qualifying accessibility when the minimal audit reproduction fails but actual VoiceOver modal focus behaves correctly? We are not asking to waive audits or declare full accessibility from a VoiceOver pass alone. I read Apple's audit guidance and modal trait documentation: https://developer.apple.com/documentation/accessibility/performing-accessibility-audits-for-your-app https://developer.apple.com/documentation/swiftui/accessibilitytraits/ismodal https://developer.apple.com/help/app-store-connect/manage-app-accessibility/sufficient-contrast-evaluation-criteria/ Related discussion https://developer.apple.com/forums/thread/823968 recommends Feedback for a different apparent Dynamic Type false positive; it does not answer these modal/contrast questions. A Feedback draft is prepared but not submitted, so I have no Feedback ID yet. No private data, identifiers, credentials, app containers or confidential application source are included.

I have an HTML select that has Spanish text in the options. When VoiceOver reads the selected option (unopened), it switches to Spanish as expected. However, when you open the select box and browse through the options, it uses the English voice to read the Spanish text. I have tried adding lang on to the select tag and the option tag but neither helps https://codepen.io/grahamfowles/pen/VYYRxMK

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

Area: iPadOS / UIKit / Accessibility Summary: In iPadOS 27.0.1, the buttons below the software keyboard have become extremely small (image), and their touch-sensitive area (clickable area) is also extremely small. This makes it difficult for users to click accurately, leading to frequent accidental touches and severely impacting the text input experience. These interface elements should conform to Apple's Human Interface Guidelines regarding the minimum touch-sensitive area (44x44 pt). Furthermore, clicking the copy button is unresponsive; a pop-up window must be accessed by clicking the input box, and then clicking paste to activate the function. After pasting, words cannot be selected via handwriting, severely affecting the user experience. Actual Performance: These buttons appear visually very crowded, with an extremely small touch-sensitive area. Increasing the system font size has no effect on these interface elements. Users find it extremely difficult to click the target button accurately, frequently triggering incorrect operations. Environment: Device: iPad with A16 chip; Operating system version: iPadOS 27.0.1 (version number: [iPadOS27]); Applications: System-level (including Safari, Notes, etc.). Impact: This issue affects accessibility and basic usability. The impact is particularly noticeable for users with large fingers, motor disabilities, or those who rely on accessibility features. The interface appears overly cramped and unintuitive.

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!

I had a VoiceOver user point out an issue with my app that I’ve definitely known about but have never been able to fix. I thought that I had filed feedback for it but it looks like I didn’t. Before I do I’m hoping someone has some insight. With Swift Charts when I tap part of a chart it summarizes the three hours and then you can swipe vertically to hear it read out details of each hour. For example, the Y-Axis is the amount of precipitation for the hour and the X-Axis is the hours of the day. The units aren't being read in the summary but they are for individual hours when you vertical swipe. The summary says something such as "varies between 0.012 and 0.082". In the AXChartDescriptor I’ve tried everything I can think of, including adding a label to the Y axis in the DataPoint but nothing seems to work in getting that summary to include units. With a vertical swipe it seems to just be using my accessibility label and value (like I would expect).

Will the Xcode accessibility audit tool be updated to better support SwiftUI? I have simple cases where I have a Form section header 'Text("some text")' that clearly works in the real world and on simulators, but I have a warning for each such scenario. Like compile warnings, too many incorrect warnings in the audit makes it hard to find the real potential accessibility issues. Xcode: 27.1 RC Here is a snippet from one of my audit reports. One of the warnings is pointing directly at the section header of my form. The code is as simple generic as one can get. As I mentioned the header is a simple Text("some text").

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.

This post is a translated and condensed version of the original article: https://developer.apple.com/forums/thread/843626. ChatGPT was used to help refine the English wording and shorten the content to meet the 7,000-word limit. The original meaning and key suggestions have been retained as much as possible. A Letter to Apple’s Accessibility Engineering Team 1. Purpose I am a visually impaired user from Hong Kong and have used iPhone VoiceOver and Zoom for many years. I have encountered issues with zoom gestures, focus handling, and pop-up navigation. Please log these proposals and diagnostic files as a formal feature request and forward them to Apple’s Asia-Pacific accessibility engineering team. 2. User Feedback Challenges Many visually impaired users face similar barriers, but official feedback often receives no follow-up. Front-line staff may lack the expertise to communicate these issues accurately, so reports can be treated as general usability problems rather than accessibility concerns. Small system changes could help many people, while active reporters represent only a fraction of those affected. 3. Screen Zoom Gestures When VoiceOver is enabled, activating Zoom with a three-finger double-tap can be difficult for people with hand tremors or limited dexterity. Coordinating three fingers makes it hard to target an area accurately, pan smoothly, and maintain consistent screen contact. The Zoom Controller can obscure content and may be accidentally activated alongside nearby controls. Apple could explore simpler gestures like Android’s magnification, which uses one finger to activate and two fingers to adjust or pan, while retaining the zoom level after the fingers leave the screen. 4. VoiceOver Gestures and Focus 4.1 Customisable Gestures Common actions can require navigating several Rotor options. Add customisable gesture combinations, such as swiping up then down or left then right, to trigger shortcuts. Customisable virtual bars along both screen edges could also provide audio or haptic feedback when touched and held, then trigger shortcuts when users swipe up or down by different distances. 4.2 Automatic Focus Grouping In third-party apps, labels and their switches are often separate VoiceOver focus elements. Automatically grouping related labels and switches would let VoiceOver announce the information and allow users to operate the switch without an extra swipe. 5. Contrast and Selection Visibility System switches can be difficult for users with low vision to distinguish. Consider a highly saturated dark-blue track when enabled, with a contrasting thumb colour, to make its state clearer than the grey disabled track. Make Settings checkmarks bolder or give selected items a dark background. In multi-select lists, consider a separate tab for selected items or automatically moving selected items to the top. This would make selection states easier to identify visually and with VoiceOver. 6. Native iOS Keyboard Keyboard size and editing: Allow keyboard-height adjustment and an optional full-screen text-editing mode for reviewing text in small third-party fields. High contrast: Offer a black keyboard with white text and keep its appearance consistent across apps when Dark Mode or Smart Invert is enabled. Dictation: Let users start dictation by holding the space bar and stop when they release it. Chinese speech-to-text: Improve language models and use sentence context to distinguish homophones and correct errors, especially for long dictation by VoiceOver users. 7. Assistive Access Assistive Access can disable VoiceOver gestures, including swiping up from the bottom to return Home. Improve compatibility between the two features. Consider adding power-saving options such as reducing screen resolution and CPU frequency, using a pure-black theme, and disabling image loading. These options could help users with older devices, visual impairments, or other accessibility needs. 8. Real-Time AI Screen Recognition Third-party apps may have buttons that cannot receive accessibility focus, missing labels, or controls that existing screen recognition cannot identify. Apple could develop system-level AI to analyse screens in real time, identify interface elements, generate labels, and make interactive controls actionable. If reliable enough, this could address more barriers at system level. Apple could also explore a shared accessibility-label database where users submit corrections that synchronise across apps and devices. 9. Navigation and Pop-up Dismissal With VoiceOver, returning to a previous page often means swiping through elements to find a small Back button. Expand its accessibility hit area so it is easier to locate and activate. Close and Cancel buttons appear in inconsistent locations, and pop-ups, nested menus, or keyboards can be difficult to dismiss. Where appropriate, tapping outside a pop-up should dismiss it by default, reducing the risk of users becoming trapped. 10. Traditional Chinese Settings and Navigation Some Traditional Chinese accessibility settings have vague names or descriptions. Clarify options such as VoiceOver “Hints” and reduce redundant announcements that may continue even after Hints are turned off. Group related settings—such as Raise to Wake, Tap to Wake, and automatic brightness—on the same page. Place icons beside titles and descriptions rather than stacking them vertically, so more options fit on screen and VoiceOver users need to scroll less. 11. Ultra Low Power Mode Add an Ultra Low Power Mode alongside Low Power Mode, with optional controls to: Pause animations and GIFs. Disable non-essential system animations and visual effects. Disable autoplay for message effects, video previews, and animated content. Disable selected display adjustments where supported. Turn off Liquid Glass effects where possible. Turn off Raise to Wake by default. Disable app suggestions, learning, and shortcuts in Search, widgets, and notifications. Place these controls in one panel, with a low-power default and the option to re-enable features individually. Reducing unnecessary animation and background processing could improve battery life, responsiveness, and device temperature, depending on the device and implementation. A simpler interface could also reduce visual distractions for VoiceOver users. 12. Summary These proposals address barriers to the everyday independence of people who are blind or have low vision. Even small changes could help users operate their devices more easily. I hope Apple will take these suggestions and users’ real-world experiences seriously. Submitted by: A visually impaired user from Hong Kong, China

Every new build of macOS 26 further breaks some part of text-to-speech or voice control. I have filed multiple bug reports on this, yet the situation gets worse, not better, with each new build. I am begging you to fix this! I am disabled and rely on these features to work. Accessibility in macOS is more than 50% of my reasons for choosing Macs over Windows. Here's some of what is currently broken: Speak announcements only works if the Samantha voice is selected. If other voices are selected either the announcements don't speak, or they default to the Samantha voice. This became broken with 26.1. Announce the time only works with some voices. I would like to use Australian English Siri 2 but with that voice selected it defaults to Samantha. This became broken with 26.4. With voice control enabled there are two menu bar icons. The blue voice control icon and an orange microphone "an application is accessing the microphone" icon. This orange icon started appearing with 26.3. For four years of macOS releases, the orange warning didn't apply to system services. And note that with voice control enabled on iOS there is no orange icon. It wastes valuable menu bar space and defeats its purpose. With that orange icon always being there I have no indication if a nefarious app starts recording me. This became broken with 26.3. Overlay shows numbers even when it is set to none. This has been broken since at least 14.0. I don't remember if it was broken in prior versions but it has been broken in every version since 14.0. The voice control control center widget is defective. If voice control is not in the menu bar (for example if I've said "Siri turn off voice control") using the control center widget to turn it on brings about the orange icon, but not the blue icon actually used for controlling voice control. If you do have the blue voice control icon and use control center to turn off voice control the blue icon stays but voice control is not enabled. This became broken in 26.0, was fixed in 26.2, broke again in 26.4. When using voice control to edit text (aka dictation mode) saying "go to the end of the line" invariably goes to the beginning of the line. Once in a blue moon it will go to the end, but there is no rhyme or reason and it's rare that it does. Since this bug was added it has worked correctly exactly twice. This became broken in 26.3 (possibly 26.4). I know I am missing some issues. Voice control and text-to-speech have new bugs with each new build of macOS 26. My main Mac is being repaired and once I get it back I'll be installing macOS 15 Sequoia on it because of these issues. These issues stop me from buying a new Mac because any new Mac will only run the broken macOS 26. I file bug reports on each build when I discover another new issue, but these reports seemingly go unread. I would suggest Apple get a focus group of disabled people together and do research into how we use macOS. Find what's broken and what works. And if Apple does this I would be glad to be a part of that group. My place, or yours. Accessibility at one time was something Apple was proud of. It was some Apple showed off. But now, I'm not so sure. It's starting to look like Apple doesn't care. I hope I'm wrong, and that Apple does care, so... Please, Apple. I am begging you. Fix broken Text-To-Speech and Voice Control!

When navigating web components (such as accordion containers or form card containers) using Safari with VoiceOver Hints enabled, VoiceOver inappropriately prefix-announces "list item" prior to speaking form field labels ( or aria-label). Inspection of the rendered DOM confirms there are no list elements (, , ) or list ARIA roles (role="list", role="listitem") anywhere in the element hierarchy or parent container. This behavior is reproducible on native/standard web components across multiple domains, including non-Salesforce test sites such as WebAIM.org. Environment & Configuration Operating System: macOS Sonoma / Sequoia (or iOS 17 / iOS 18) Browser: Safari (Latest Stable & WebKit Nightly) Assistive Technology: VoiceOver Required VoiceOver Settings: VoiceOver Utility > Verbosity > Hints → Enabled Steps to Reproduce Enable VoiceOver (Cmd + F5 on macOS). Ensure VoiceOver Hints are turned ON under VoiceOver Utility > Verbosity > Hints. Open Safari and navigate to any standard web container containing a form field (e.g., an accordion element or card container wrapping standard text inputs). Use VoiceOver navigation key commands (VO + Left/Right Arrow or Tab navigation) to place focus onto a form field label or text input inside the container. Listen to the VoiceOver speech output string. Expected Behavior VoiceOver should announce only the accessible name/label, input role, and state. Example: "First Name, edit text" Actual Behavior VoiceOver speaks "list item" prior to reading the label and role. Example: "List item, First Name, edit text" Code / DOM Verification To verify that this is an accessibility tree/rendering engine misinterpretation rather than a markup bug, the target container was inspected: HTML

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.

I am testing out the new auto-generated subtitles feature on iOS 27 and tvOS 27. It works on iOS, but not on tvOS. Very same HLS videos. Anyone have any experience with auto-generated subtitles on tvOS 27? AFAICT, there is no special code needed to enable this feature for our apps, correct?

Hello, I'm having a very hard time finding where any documentation or session or any WWDC related announcement related to the FaceTime API that was mentioned in this press release last month. https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." Can anyone please point me in the right direction? I have searched everywhere in Developer.app, documentation released during this WWDC, and here in the Forums and have yet to find anything.

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.

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!

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

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!