I am testing the accessibility feature available in the Settings app called "Speak Screen". The help text in the Setting app states that swiping down with two fingers will cause the screen content to be spoken. However, I've been unable to get this feature to work. Every time I try the double finger swipe down, it behaves the same as the single finger swipe down gesture. Usually this manifests as making scroll views bounce. I've tried toggling the feature on and off, turning off Reachability, and rebooting my phone, but I can't get the speak screen gesture to work. If I access the speak screen feature from the "Speech Controller" button, then the screens content is spoken, as expected, so I know the feature is enabled. It's just the gesture that doesn't work. Is there something else I need to do to get this gesture to work? I don't want to tell my users to turn this feature on if I can't verify that the gesture will work with my app.

Say I have a UI element that moves on the screen. Is it possible to update its accessibility frame as it moves while VoiceOver is focused on it? From my tests, VoiceOver ignores UIAccessibilityLayoutChangedNotification if it's sent repeatedly in a short period of time on iOS, while sending NSAccessibilityLayoutChangedNotification on macOS triggers VoiceOver to reannounce the focused element repeatedly.

Hello I tried implementing the ASAM for macOS as per apple guidelines with configuration profile mentioned here but didn't had any success. Then Apple suggested to use requestGuidedAccessSession in macOS but that is only supported in macOS Catalyst but that also didn't work with valid config profiles too. Did anyone get success with ASAM mode without assessment entitltlement?

Hello, I’m in the process of enrolling my business (Carzo Rent A Car, Prishtine, Kosovo) in the Apple Developer Program, but I have been waiting for my D-U-N-S number to be issued. I submitted the request to Dun & Bradstreet on July 28, 2025 (Case #9142648) and have only received a system-generated email with a tracking ID (#9086421). There has been no further update. My questions are: Is there a way for Apple to expedite or provisionally approve my enrollment while the D-U-N-S number is pending? How long does Apple typically wait for D&B updates before the enrollment is affected? Are there any alternative steps I can take to avoid further delays? Thank you for your guidance.

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() } }```

I'm reposting here my FB17602742, submitted yesterday: The strong wording of this message comes from years of Apple ignoring the needs of users who can't tolerate UI animations and convulsions. At this point, it's clear that Apple is either intentionally harming users like me or simply doesn't care about meeting even the most basic accessibility standards on macOS. Yes, many UI animations and convulsions can, fortunately, be disabled - but not through straightforward UI controls. Instead, users are forced to look for obscure Terminal commands found scattered across the Internet. The "Reduce motion" checkbox in System Settings is simply a fake control that doesn't do anything - instead of actually disabling all UI animations and convulsions. What's worse, two of the most offensive UI animations cannot be disabled at all. Apple has consistently dismissed requests to let users disable the following UI animations: Scroll bar rollover highlight effect (introduced on macOS 10.7.3). Every time the cursor passes over a scroll bar, it gets highlighted. This draws the user's attention to random scroll bars for no reason - just because the cursor happened to pass over them. It results in HUNDREDS of unnecessary, annoying events of distraction daily!
 Expand/collapse animation of NSOutlineView (e.g., when opening/closing folders in the list view in the Finder, or any other app using outline views). This animation is extremely distracting, irritating, and time-wasting. Global Accessibility Awareness Day is approaching. Dear Apple, Please adhere to the most basic accessibility standards. Stop the needless suffering of countless users like me. Let us disable the two aforementioned UI convulsions. Thank you for your attention to the issue.

I'm encountering an issue related to BLE device discovery on iOS. I have a BLE peripheral device that I initially connected to using an iOS device. After this connection, the BLE device's advertised name was programmatically changed by the peripheral. Now, when I try to scan for this device using other iOS devices, it does not appear in the scan results in most apps — including nRF Connect and our own custom BLE app that uses CoreBluetooth. A few observations: The device is definitely powered on and advertising (confirmed via Android). The name change is reflected correctly on Android and on the iOS device that originally connected to it. Other iOS devices no longer see the device in their scan list.

Triple tap for screenshot->notification->triple tap detected becomes a part of the screenshot and obscures the top part of screenshot. Thanks

Hi, I’ve been reviewing the Apple Wallet provisioning documentation (Getting Started with Apple Pay In-App Provisioning_ Verification_Security_Wallet Extensions )and had a few questions regarding the color path recommendation (Green, Yellow, Orange, Red) returned during the in-app provisioning flow: Who determines the color path—is it Apple directly, the Payment Network Operator (PNO), or both? What criteria are used to determine the color path (e.g., device info, Apple ID reputation, past provisioning attempts)? At what point in the provisioning flow is the color path recommendation received? Is it included in the response after the PKAddPaymentPassRequest is submitted? Is it accessible through any specific property or callback in the delegate method? Additionally, for Orange Path with Reason Code 0G, I understand that in-app verification is not allowed and must be handled via tenured channels (e.g., SMS/email). Can you confirm if this logic still applies for requests initiated from within the issuer's iOS app? Would appreciate any clarification or pointers to related documentation.

I have subscribed to the developer program, but it’s already been a day and it still shows “is not enrolled in the Apple Developer Program.”

I have a TabView with a sample tabItem as follows: .tabItem { Label ("Import", systemImage:"doc.on.doc") .accessibilityLabel("Import Text") } But accessibility settings for large display size on does not seem to work, nor do dynamic font sizes: .tabItem { Label ("Import", systemImage:"doc.on.doc") .font(.largeTitle) .accessibilityLabel("Import Text") } The tabItems appear as a fixed size. The tab contents scale well, so this does not look pleasant at all. Is this a known bug in SwiftUI?

Hi! I have noticed a few glitches as well as some overall unfortunate cons with the assistive access mode. Alarms, timers, stopwatch, etc. do not sound or alert. However, I have an infant monitor app and I do get that sound alert so I know it is possible.. do I need to download a separate alarm app for it to work? Cannot make FaceTime calls with favorite contacts. Find My iPhone cannot jump to the maps app. Camera cannot zoom in or out. Photos cannot be deleted, edited, or shared in a shared album in the photos app. Photos/videos cannot be sent in messages. Spotify cannot be accessed from the lock screen. Apps do not stay open if you lock the phone screen or leave it on too long without touching the screen (auto locks). There is no flashlight option. I downloaded an app to have this feature but without being touched the screen will lock which shuts off the flashlight feature in the app until I unlock the phone again.

I am building a language learning app for a Unlisted Primary Language. Any suggestions or heads ups? My plan is to select english and go with it. Its unfortunate that I have to list a language learning app incorrectly and a tag for that language probably does not exist across the apple system.

The Text view seems to automatically prevent orphaned words on screen, but barring exceptional circumstances such as the font size being too large. I couldn't find any documentation on this behaviour, how to configure, and would also be very interested in how it's implemented? Thanks!

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

iOSアプリでNEAppPushSessionを使い、NEAppPushDelegateの通知を受けてCallKitの着信画面を表示する実装をしていますが、以下の問題に直面しています。 8/13 ログにて下記のエラーが頻発しました。 通知の受け取りテストを約120回してその間ずっとこのエラーが出ていました。 エラー 2025-08-14 11:27:06.793073 +0900 nesessionmanager NESMAppPushSession[SimplePushDefaultConfiguration:7B7218F3-94B5-4AE5-9B9E-94E176694D02] failed to report incoming call to CallKit, error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process.} このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら通知の監視は開始しているようです。 15時間後の8/14 時間をあけたからか、再度通知が来るようになりました。 ですが再度通知の受け取りテストを行った時に同じエラーログが出ました。 再度通知テストを約120回程行ったら、このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら今回も通知の監視は開始しているようです。 15時間後の8/15 今日は15時間かけても通知を取得できませんでした。 ですが同じく通知の監視は開始していそうです。 iPhoneの再起動、Xcodeのクリーンアップ、アンインストールして再インストールなどしても通知は来ないままでした。 また、不思議なことに通知が来ない事象が起きた端末以外でも同じように通知を取得することができません。 他の通知は受け取ることができますが独自の通知であるNEAppPushManagerだけ通知を取得することができません。 質問です。 再度通知を出すためには何をすれば良いでしょうか。 この事象は4099エラーを出しすぎたことにより発生する障害なのでしょうか。 4099エラーを出ている原因は何でしょうか。

I am invoking the UIImagePickerController of type UIImagePickerControllerSourceTypePhotoLibrary from my viewController. I want shift the keyboard focus to the Cancel button which is the first interactive element on the gallery picker. When a user has full keyboard access turned on they should be able to tap tab and interact with the gallery picker modal. How do I achieve this?

In the app I'm working on, I have a SwiftUI View embedded in a UIKit Storyboard. The SwiftUI View holds a menu with a list of payment tools, and the ForEach loop looks like this: ForEach(self.paymentToolsVM.paymentToolsItems, id: \.self) { paymentTool in Button { navigationCallback(paymentTool.segueID) } label: { PaymentToolsRow(paymentToolName: paymentTool.title, imageName: paymentTool.imageName) .accessibilityElement() .accessibilityIdentifier("Billing_\(paymentTool.title.replacingOccurrences(of: " ", with: ""))") } if paymentTool != self.paymentToolsVM.paymentToolsItems.last { Divider() } } So you can see the accessibility ID is there, and it shows up properly when I open up Accessibility Inspector with the simulator, but the testing script isn't picking up on it, and it doesn't show up when the view is inspected in Appium. I have other SwiftUI views embedded in the UIKit view, and the script picks up the buttons on those, so I'm not sure what's different about this one. If it helps, the script is written in Java with the BDD framework. I can try to get the relevant part of the script if anyone thinks that would be helpful. Otherwise, is there anything else I can try?

Double-tap three fingers and drag to change zoom” should suppress “Three Finger to Drag”. Currently these gestures are triggered simultaneously, for no real reasons. I saw different behaviors for different environments, but none is desired. Current and desired behavior: This seems an issue so I filed a feedback.

Issue: When using the shortcut Command + Delete to clear a line of text, the next character I type in Thai unexpectedly appears as an English character, even though the input source is still set to Thai. After that, subsequent characters return to Thai as expected. Details: Affected apps: Notes, Messages, and some other native apps Not affected: Browser text fields (Safari, Chrome, etc.) Does not occur when using Option + Delete or just Delete macOS [insert beta version + build number] Mac model: [insert model] Input sources: Thai – Kedmanee, English – U.S. Steps to reproduce: Open Notes (or Messages). Switch to Thai input. Type a few Thai words. Press Command + Delete. Type again — the first character shows up in English. Expected: First character should remain in Thai, consistent with the active input source. Actual: First character shows as English, then input switches back to Thai.