We are unable to programmatically enable AppleScript automation for VoiceOver on macOS 15 (Sequoia) In macOS 15, Apple moved the VoiceOver configuration from: ~/Library/Preferences/com.apple.VoiceOver4/default.plist to a sandboxed path: ~/Library/Group Containers/group.com.apple.VoiceOver/Library/Preferences/com.apple.VoiceOver4/default.plist Steps to Reproduce: Use a macOS 15 (ARM64) machine (or GitHub Actions runner image with macOS 15 ARM). Open VoiceOver: open /System/Library/CoreServices/VoiceOver.app Set the SCREnableAppleScript flag to true in the new sandboxed .plist: plutil -replace SCREnableAppleScript -bool true ~/Library/Group\ Containers/group.com.apple.VoiceOver/Library/Preferences/com.apple.VoiceOver4/default.plist Confirm csrutil status is either disabled or not enforced. Attempt to control VoiceOver via AppleScript (e.g., using osascript voiceOverPerform.applescript). Observe that the AppleScript command fails with no useful output (exit code 1), and VoiceOver does not respond to automation.

I am building a language learning app for a unlisted primary language. My plan is to go with english. Any other suggestions or heads up? Check screenshot. Its unfortunate that i have to tag a language learning app incorrectly and a tag for that language probably does not exist across the apple system.

I wrote this in the regular forums and they deleted it and told me to write it here because it was dealing with unreleased software. I read that Launchpad is disappearing in Tahoe and I have real concerns about that. For me, that is an accessibility issue. I have both memory problems and scanning problems. So having my apps organized into categories is extremely important to me. Just today I needed to find an app that I didn't remember the name of and I rarely use, but when I need it, it is important to me. Just to see if I could find it without launchpad, I scanned my applications folder and I couldn't find it. I went to launchpad and to the category I knew it was in and it was right there, easy for me to find. Please don't take away our organization options.

Hi, I've wrapped AVRoutePickerView in SwiftUI using pretty much the code given here, with a few changes: func makeUIView(context: Context) -> UIView { let routePickerView = AVRoutePickerView() // Configure the button's color. //routePickerView.delegate = context.coordinator //routePickerView.backgroundColor = .secondarySystemBackground routePickerView.tintColor = .accent routePickerView.activeTintColor = .accent // Indicate whether your app prefers video content. routePickerView.prioritizesVideoDevices = false return routePickerView } I commented out routePickerView.delegate = context.coordinator because it doesn't compile; context.coordinator is of type Void and I'm not sure how to fix that. I'm not sure if that has anything to do with the issue. Anyway, this works fine without VoiceOver; if I tap the button, I get the AirPlay popover. But in VoiceOver, if I select the button and double-tap, nothing happens… it just reads the button's accessibilityLabel again. How can I get the AirPlay popover to show in VoiceOver?

There is an issue with Help Books that started with the release of macOS 14.4. The issue is that when an app attempts to go directly to a Help Book page, the help viewer opens to the Help Book's main index page, rather than the specific page requested. As I investigated the issue I found that the requested page was actually part of help viewer's navigation history, and all I had to do was to click the Back navigation arrow and the requested page would be displayed. So it seems like the requested page is momentarily visited but is then (for whatever reason) quickly replaced by the main index page. Our app uses the AHGotoPage() API for directly accessing our Help Book's pages. This is the same mechanism/code that our app has used for more than a decade and has never caused us any issues. Everything works fine on macOS 14.3.0 and earlier. I've scoured the documentation and can't find any newer APIs for accessing Help pages. I've also tried various other things (e.g. reworking the code, creating new indexes for the app's Help, etc.), but none of it seems to make a difference. As far as I can tell, the issue seems to stem from some change made to the OS. So my questions are: Is this a known bug? And if so, is there any ETA on a fix? Is there something different we should be doing for newer versions of the OS (create indexes differently, use a different API, etc.)?

Feedback number: FB20451665 When building with Xcode 26, Voice Over is reporting an extra tab when swiping through tabs. Please see the sample project below: /* This is a Sample project to show that I believe there is a Voice Over bug in iOS 26. When swiping through tabs with Voice Over active, there always appears to be an extra tab. Here I have 5 tabs, when on tab one VO reads out tab 1 of 6, then tab 2 of 6, all the way to the last tab, when voice over reads out tab 5 of 6. Never tab 6 of 6. Is there a possibility that voice over is picking up the underlying `more` tab and reading that out? This has also been reportedly found in the Files app here: https://www.applevis.com/comment/195441#comment-195441 */ struct ContentView: View { var body: some View { TabView { /// Activating this has Voice over telling us there are 6 Tabs. Tab(RootTab.home.title, systemImage: "circle.fill") { Text("This is the \(RootTab.home.title.capitalized) screen") } .accessibilityLabel("\(RootTab.home.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.home.title.capitalized) tab") Tab(RootTab.diary.title, systemImage: "circle.fill") { Text("This is the \(RootTab.diary.title.capitalized) screen") } .accessibilityLabel("\(RootTab.diary.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.diary.title.capitalized) tab") Tab(RootTab.meals.title, systemImage: "circle.fill") { Text("This is the \(RootTab.meals.title.capitalized) screen") } .accessibilityLabel("\(RootTab.meals.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.meals.title.capitalized) tab") Tab(RootTab.knowledge.title, systemImage: "circle.fill") { Text("This is the \(RootTab.knowledge.title.capitalized) screen") } .accessibilityLabel("\(RootTab.knowledge.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.knowledge.title.capitalized) tab") Tab(RootTab.profile.title, systemImage: "circle.fill") { Text("This is the \(RootTab.profile.title.capitalized) screen") } .accessibilityLabel("\(RootTab.profile.title.capitalized) tab") .accessibilityHint("Double tap to open the \(RootTab.profile.title.capitalized) tab") /// Activating this also has Voice over telling us there are 6 Tabs. // ForEach(RootTab.allCases, id: \.self) { tab in // // Text("This is the \(tab.title.capitalized) screen") // .tabItem { // Label(tab.title.capitalized, systemImage: "circle.fill") // } // .accessibilityLabel("\(tab.title.capitalized) tab") // .accessibilityHint("Double tap to open the \(tab.title.capitalized) tab") // } } } enum RootTab: CaseIterable { case home case diary case meals case knowledge case profile var title: String { switch self { case .home: "home" case .diary: "diary" case .meals: "meals" case .knowledge: "knowledge" case .profile: "profile" } } } } I'm curious if anyone else can see this issue, or if anyone knows of a workaround for it.

We recently adopted our app to Liquid Glass and received a complaint from a visually impaired user that VoiceOver does not read out the number of unread items in the tab bar anymore. We checked and it seems that before iOS 26/Liquid Glass, setting a tab bar item's badgeValue property also set an appropriate text to its accessibilityValue property (something like "3 items"). But with Liquid Glass tab bars, this does not seem to be the case anymore. We fixed this by providing our own accessibility value, but we're wondering whether this change was a deliberate choice or simply a bug? If this new behavior is considered a bug, I would post a bug report.

I’ve noticed that the VoiceOver reads currency amounts correctly when they are below thousand. Then, for higher amounts, for example 12.225,34 € VoiceOver reads ‘twelve point two two five thirty four euros’ If the amount is formatted without the thousand separator (12225,34 €) this problem doesn’t exist. (VO reads twelve thousand two hundred and twenty five euros and thirty four cents) Why is the thousand separator a problem for VoiceOver if this formatting is coming from the currency and locale? This issue exists in English. I changed my device language to Italian and German and in both cases the number was read correctly even with the separator. Is there a way to make it work in English?

Our application, https://apps.apple.com/us/app/gamecontroller-mapper/id6737088417 which maps game controller inputs to keyboard/mouse events system-wide, has stopped functioning properly after the macOS 15.4 update. Specifically, the app can no longer capture game controller inputs when running in the background, severely impacting its core functionality. Environment macOS version: 15.4 Previous working versions: All versions prior to 15.4 App type: Background utility with accessibility permissions Hardware: All game controller brands compatible with macOS Detailed Description Before macOS 15.4 Our application correctly captured game controller inputs from any brand connected to Mac and successfully translated them to keyboard/mouse events system-wide. Users could control any application (e.g., scrolling through documents in Preview using controller buttons) while our app ran in the background with the accessibility permissions granted. After macOS 15.4 The application only works when it has active focus (is in the foreground). When any other application gains focus, our app completely stops receiving or detecting any input events from the game controller while running in the background. For instance, pressing the 'down' button on the controller while another app is active results in no event being registered within our application. We've tried updating the app to work in accessory mode (in the menubar), but the issue persists. Steps to Reproduce Install our application on macOS 15.3 or earlier Grant accessibility permissions when prompted Connect a compatible game controller (e.g., Xbox or other controller) Open another application (e.g., Preview with a PDF document) Press buttons on the controller to navigate the document without touching the keyboard Expected result on 15.3: Controller inputs are translated to keyboard events, even when our app is in the background Upgrade to macOS 15.4 Repeat steps 2-5 Actual result on 15.4: Controller inputs are only translated to keyboard events when our application has focus Technical Implementation Our app uses: CGEvent.tapCreate() to create a global event tap CGEvent for simulating keyboard and mouse events GCController.extendedGamepad?.valueChangedHandler for detecting controller inputs Proper NSAccessibilityUsageDescription and appropriate entitlements GCController.shouldMonitorBackgroundEvents = true to ensure controller events continue when the app is inactive Possible Relation to Recent Changes We noticed in the macOS 15.4 Release Notes: Game Controller - Resolved Issues: Fixed: Game controllers might stop responding when accessibility features, such as Voice Over, are enabled. (141497799) We suspect this fix might have introduced a regression or intentional limitation affecting applications like ours that rely on background event simulation with game controller input. Impact This change severely impacts: Applications designed to use game controllers as assistive input devices for users who may have difficulty using traditional keyboard and mouse inputs Applications for media control, presentation navigation, and other similar use cases Users who rely on our application for accessibility purposes Questions Is this an intentional security change or an unintended side effect of the controller fix mentioned in the release notes? Are there any new APIs or alternative approaches we should implement to restore functionality? If this is a system bug, when can we expect a fix? We would greatly appreciate any guidance on how to restore our application's functionality. Thank you for your assistance.

Hi all, I’ve got a usability question about accessibility navigation. My app has a lot of carousels (horizontally scrolling lists of content with far more elements than can fit on the screen). Often, these are just images, but sometimes, they’re cards with multiple subelements. In our previous implementation, each card was a single accessibility element, and we exposed the subelements as accessibility custom actions. Despite this, users frequently mentioned navigating with VoiceOver as a pain point. It takes a long time to navigate through and navigate past these carousels. To solve this, I converted my carousels into a single adjustable element, so users can navigate through it with one swipe, and they can still access the elements by adjusting the values up and down. I got this advice from this 2018 WWDC talk. Is this still the recommended advice? Or is there a new, preferred way to do this? Additionally, I had to get a little creative with the second carousel, the one with multiple subelements. Some of these were interactive (imagine a card with a description, an upvote button, and a downvote button). Adjustable elements override the accessibility custom actions VoiceOver gesture, so I can’t expose the individual buttons as actions. Instead, I made each subelement in each card in the carousel one of the adjustable values. Swiping up would go from description 1 to upvote button 1 to downvote button 1 to description 2, etc. Double tapping with VoiceOver would perform whatever action the carousel is currently on. So if I adjust the value to the element at index 2 (say, downvote 1), double tapping would trigger the downvote button’s action. Does this make sense? Is there a better way to do this? This seemed to be the best compromise between screenreader navigation speed, exposing all actions, and the existing UI.

My team has a robust digital accessibility program and processes for WCAG conformance in our apps. Because of this, there are definitely accessibility defects that get caught and addressed in order of impact and business priority like any other bug. Obviously we want to aim for 100% accessibility for our users, but it's a continual work in progress as new enhancements or changes are released. I'm stuck on the appropriate measurement to indicate support. If we have 50 common tasks and the most central 10 tasks are solid but some supporting (but also common) tasks have a contrast fail or accessibleLabel missing, does that make the whole app not supporting the feature? If "completing the task" is the rubric there are a whole range of interpretations for that. In a complex app, I anticipate that a group like ours will have strong support for many of the Accessibility Nutrition Labels accessibility features across tasks and devices, but realistically never be 100% free of defects for a given Apple Accessibility feature, even among core tasks. As I consider the next steps for Nutrition Labels, I do not see anything in the documentation that gives a sort of baseline or measurement for inclusion. We plan to test all steps to complete a task, and log defects accordingly with an assigned timeline for fixing them (as would be true for functional defects).

There are several ways we are supposed to be able to control a11y (accessibility) focus in FKA (Full Keyboard Access) mode. We should be able to set up an @AccessibilityFocusState variable that contains an enum for the different views that we want to receive a11y focus. That works from VO (VoiceOver) but not from FKA mode. See this sample project on Github: https://stackoverflow.com/questions/79067665/how-to-manage-accessibilityfocusstate-for-swiftui-accessibility-keyboard Similarly, we are supposed to be able to use accessibilitySortPriority to control the order that views are selected when a user using FKA tabs between views. That also works from VO but not from FKA mode. In the sample code below, the `.accessibilitySortPriority() ViewModifiers cause VO to change to a non-standard order when you swipe between views, but it has no effect in FKA mode. Is there a way to either set the a11y focus or change the order in which the views are selected that actually works in SwiftUI when the user is in FKA mode? Code that should cause FKA to tab between text fields in a custom order: struct ContentView: View { @State private var val1: String = "val 1" @State private var val2: String = "val 2" @State private var val3: String = "val 3" @State private var val4: String = "val 4" var body: some View { VStack { TextField("Value 1", text: $val1) .accessibilitySortPriority(3) VStack { TextField("Value 2", text: $val2) .accessibilitySortPriority(1) } HStack { TextField("Value 3", text: $val3) .accessibilitySortPriority(2) TextField("Value 4", text: $val4) .accessibilitySortPriority(4) } } .padding() } }```

This was working a few days ago, but it has since stopped and I can't figure out why. I've tried resetting TCC, double-checking my entitlements, restarting, deleting and rebuilding, and nothing works. My app is a sandboxed macOS SwiftUI LSUIElement app that, when invoked, checks to see if the frontmost process is Terminal, then tries to get the frontmost window’s title. func getFrontmostWindowTitle() throws -> String? { let trusted = AXIsProcessTrusted() print("getFrontmostWindowTitle AX trusted: \(trusted)") guard let app = NSWorkspace.shared.frontmostApplication else { return nil } let appElement = AXUIElementCreateApplication(app.processIdentifier) var focusedWindow: AnyObject? let status = AXUIElementCopyAttributeValue(appElement, kAXFocusedWindowAttribute as CFString, &focusedWindow) guard status == .success, let window = focusedWindow else { if status == .cannotComplete { throw Errors.needAccessibilityPermission } return nil } var title: AnyObject? let titleStatus = AXUIElementCopyAttributeValue(window as! AXUIElement, kAXTitleAttribute as CFString, &title) guard titleStatus == .success else { return nil } return title as? String } I recently renamed the app, but the Bundle ID has not yet changed. I have com.apple.security.accessibility set to YES in the Entitlements file (although i had to add it manually), and a NSAccessibilityUsageDescription string set in Info.plist. The first time I ran this, macOS nicely prompted for permission. Now it won't do that, even when I use AXIsProcessTrustedWithOptions() to try to force it. If I use tccutil to reset accessibility and apple events, it still doesn't prompt. If I drag my app from the build products folder to System Settings, it gets added to the system TCC DB (not the user DB). It shows an auth value of 2 for my app: % sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" "SELECT client,auth_value FROM access WHERE service='kTCCServiceAccessibility' OR service='kTCCServiceAppleEvents';" com.latencyzero.<redacted>|2 <redactd> I'm at a loss as to what went wrong. I proved out the concept earlier and it worked, and have since spent a lot of time enhancing and polishing the app, and now things aren't working and I'm starting to worry.

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've identified a regression in iOS 26.0 and 26.1 Beta 4 where AVSpeechSynthesisVoice(language:) no longer respects user-selected voices from Accessibility settings. Issue: When users select a specific voice in Settings → Accessibility → Spoken Content → Voices, calling AVSpeechSynthesisVoice(language:) returns the system default voice instead of the user's selection. This worked correctly in iOS 18.6.2. Particularly affects: Third-party speech synthesis voices (CereProc, Grammatek, etc.) Apps relying on automatic voice selection based on user preferences Example: // User selected CereProc Heather for en-GB in Accessibility settings let voice = AVSpeechSynthesisVoice(language: "en-GB") print(voice?.name) // iOS 18.6.2: "HEATHER", iOS 26: "Daniel" (system default) Interesting observation: The new Accessibility Reader feature in iOS 26 correctly uses the user-selected voice, but Tap to Speak and the API both ignore the setting. Tested methods: AVSpeechSynthesisVoice(language:) AVSpeechUtterance auto-selection Reflection for new APIs All return the system default voice, not the user's preference. Filed: FB[20271264] Has anyone else encountered this? Any known workarounds to programmatically access the user's preferred voice selection?

Hi Apple Developer Community, I'm experiencing persistent issues with the Apple Search Ads API since today morning (August 16, 2025). My application keeps getting "Service Unavailable" errors when trying to connect to the API endpoints. Error Details: Error Message: "Service Unavailable" HTTP Status: 503/500 API Endpoint: https://api.searchads.apple.com/api/v5/* Frequency: Consistent failures since August 16, 2025 What I've Tried: Verified API credentials and certificates are valid Tested multiple API endpoints Checked network connectivity The API was working fine until yesterday, and no changes were made to our implementation. Any insights or updates from the community would be greatly appreciated. Thanks in advance for your help!

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.

Please note the error after the iOS 26 update I updated to the beta version of iOS 26, but the phone did not charge more than one percent and it reboots every couple of minutes when charging. In the settings, the maximum battery capacity says 0% the phone did not fall before the update, everything was fine, I updated it and this stuff started Even the recovery can't be done because it restarts in the middle of the process.

Hi everyone, I've encountered a rare and strange crash in my app that I can't consistently reproduce. The crash seems to occur deep within Apple's internal frameworks, and I can't pinpoint which line of my own code is causing it. Here's the crash stack trace: #44 AXSpeech SIGSEGV SEGV_ACCERR 0 CoreFoundation ___CFCheckCFInfoPACSignature + 4 1 CoreFoundation _CFRunLoopSourceSignal + 28 2 Foundation _performQueueDequeue + 492 3 Foundation ___NSThreadPerformPerform + 88 4 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 5 CoreFoundation ___CFRunLoopDoSource0 + 176 6 CoreFoundation ___CFRunLoopDoSources0 + 340 7 CoreFoundation ___CFRunLoopRun + 828 8 CoreFoundation _CFRunLoopRunSpecific + 608 9 Foundation -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 10 TextToSpeech _TTSCFAttributedStringCreateStringByBracketingAttributeWithString + 776 11 Foundation ___NSThread__start__ + 732 12 libsystem_pthread.dylib __pthread_start + 136 Sometimes, instead of line 10 referencing _TTSCFAttributedStringCreateStringByBracketingAttributeWithString, it shows: 10 TextToSpeech LogWarning(char const*, ...) + 7288 Has anyone experienced a similar issue or know what might be triggering this crash? Any guidance on how to investigate or resolve this would be greatly appreciated. Thank you!

I'm developing a calculator app and working to ensure a great experience for both VoiceOver and Braille display users. For expressions like (2+3)×5, I need two different accessibility outputs: VoiceOver (spoken): A descriptive string like “left paren two plus three right paren times five,” provided via .accessibilityValue. I'm using a custom spellOut function since VoiceOver doesn't announce parentheses—which are kind of important when doing math! Braille (symbolic): The literal math string (2+3)×5, provided using .accessibilityCustomContent("", ...), with an empty label so it’s not spoken aloud. The issue: I don’t have access to a Braille display device and Xcode’s Accessibility Inspector doesn’t seem to show the custom content. Is there any way to confirm that custom Braille content is being set correctly in Simulator or with other tools? Or…is there a "math mode" in VoiceOver that forces it to announce parentheses? Any advice or workarounds would be much appreciated! Thanks, Uhl