Hi, On iOS, I'd like to mark views that are inside a LazyVStack as headers for VoiceOver (make them appear in the headings rotor). In a VStack, you just have add .accessibilityAddTraits(.isHeader) to your header view. However, if your view is in a LazyVStack, that won't work if the view is not visible. As its name implies, LazyVStack is lazy so that makes sense. There is very little information online about system rotors, but it seems you are supposed to use .accessibilityRotor() with the headings system rotor (.accessibilityRotor(.headings)) outside of the LazyVStack. Something like the following. .accessibilityRotor(.headings) { ForEach(entries) { entry in // entry.id must be the same as the id of the SwiftUI view it is about AccessibilityRotorEntry(entry.name, id: entry.id) } } It kinds of work, but only kind of. When using .accessibilityAddTraits(.isHeader) in a VStack, the view is in the headings rotor as soon as you change screen. However, when using .accessibilityRotor(.headings), the headers (headings?) are not in the headings rotor at the time the screen appears. You have to move the accessibility focus inside the screen before your headers show up. I'm a beginner in regards to VoiceOver, so I don't know how a blind user used to VoiceOver would perceive this, but it feels to me that having to move the focus before the headers are in the headings rotor would mean some users would miss them. So my question is: is there a way to have headers inside a LazyVStack (and are not necessarily visible at first) to be in the headings rotor as soon as the screen appears? (be it using .accessibilityRotor(.headings) or anything else) The "SwiftUI Accessibility: Beyond the basics" talk from WWDC 2021 mentions custom rotors, not system rotors, but that should be close enough. It mentions that for accessibilityRotor to work properly it has to be applied on an accessibility container, so just in case I tried to move my .accessibilityRotor(.headings) to multiple places, with and without the accessibilityElement(children: .contain) modifier, but that did not seem to change the behavior (and I could not understand why accessibilityRotor could not automatically make the view it is applied on an accessibility container if needed). Also, a related question: when using .accessibilityRotor(.headings) on a screen, is it fine to mix uses of .accessibilityRotor(.headings) and .accessibilityRotor(.headings)? In a screen with multiple type of contents (something like ScrollView { VStack { MyHeader(); LazyVStack { /* some content */ }; LazyVStack { /* something else */ } } }), having to declare all headers in one place would make code reusability harder. Thanks

I have a Twitter account that I registered with Apple id and I still don't know the PIN and I'm having a problem with it knowing the PIN I need help privaterelay.appleid.com

VoiceOver reads out all visible content on the screen, which is essential for visually challenged users. However, this raises a privacy concern—what if a user accidentally focuses on sensitive information, like a bank account password, and it gets read aloud? How can developers prevent VoiceOver from exposing confidential data while still maintaining accessibility? Are there best practices or recommended approaches to handle such scenarios effectively?

I have implemented a SwiftUI view containing a grid of TextField elements, where focus moves automatically to the next field upon input. This behavior works well on iOS 16 and 17, maintaining proper focus highlighting when keyboard full access is enabled. However, in iOS 18 and above, the keyboard full access focus behaves differently. It always stays behind the actual focus state, causing a mismatch between the visually highlighted field and the active text input. This leads to usability issues, especially for users navigating with an external keyboard. Below is the SwiftUI code for reference: struct AutoFocusGridTextFieldsView: View { private let fieldCount: Int private let columns: Int @State private var textFields: [String] @FocusState private var focusedField: Int? init(fieldCount: Int = 17, columns: Int = 5) { self.fieldCount = fieldCount self.columns = columns _textFields = State(initialValue: Array(repeating: "", count: fieldCount)) } var body: some View { let rows = (fieldCount / columns) + (fieldCount % columns == 0 ? 0 : 1) VStack(spacing: 10) { ForEach(0..<rows, id: \.self) { row in HStack(spacing: 10) { ForEach(0..<columns, id: \.self) { col in let index = row * columns + col if index < fieldCount { TextField("", text: $textFields[index]) .frame(width: 40, height: 40) .multilineTextAlignment(.center) .textFieldStyle(RoundedBorderTextFieldStyle()) .focused($focusedField, equals: index) .onChange(of: textFields[index]) { newValue in if newValue.count > 1 { textFields[index] = String(newValue.prefix(1)) } if !textFields[index].isEmpty { moveToNextField(from: index) } } } } } } } .padding() .onAppear { focusedField = 0 } } private func moveToNextField(from index: Int) { if index + 1 < fieldCount { focusedField = index + 1 } } } struct AutoFocusGridTextFieldsView_Previews: PreviewProvider { static var previews: some View { AutoFocusGridTextFieldsView(fieldCount: 10, columns: 5) } } Has anyone else encountered this issue with FocusState in iOS 18? I really do believe that this is a bug strictly connected to keyboard navigation since I experienced similar problem also on UIKit equivalent of the view. Any insights or suggestions would be greatly appreciated!

I have a couple follow up questions after the "Accessibility technologies group lab". I know it was briefly mentioned that user feedback is an excellent way to grow inclusivity in the design an app and utilizing these forums were one for example. Is inviting folks here on the forum via test flight a reasonable approach to this for a solo developer? Are there other strategies, avenues, or examples to promote user feedback?

When turning VoiceOver ON, GCController does not send button press events for "Button A" and "Button Center". This happens when using Siri 2nd generation remote (with dedicated arrow buttons on the circle around center button) and also when using iOS remote. I didn't test it on old Siri 1st generation with touchpad without arrow buttons. Example: gameController.microGamepad?.allButtons.forEach { button in button.valueChangedHandler = { [weak self] _, _, _ in self?.buttonHandler(gameController: gameController, button: button) } private func buttonHandler(gameController: GCController, button: GCControllerButtonInput) { print("BUTTON: Pressed \(button.description) isPressed=\(button.isPressed) isTouched=\(button.isTouched)") } #endif VoiceOver ON (incorrect behavior): BUTTON: Pressed Direction Pad Left (value: 0.030, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Down (value: 0.079, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Left (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Down (value: 0.000, pressed: 0) isPressed=false isTouched=false VoiceOver OFF (correct behavior): BUTTON: Pressed Direction Pad Left (value: 0.137, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Direction Pad Up (value: 0.078, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button A (value: 1.000, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button Center (value: 1.000, pressed: 1) isPressed=true isTouched=true BUTTON: Pressed Button A (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Button Center (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Left (value: 0.000, pressed: 0) isPressed=false isTouched=false BUTTON: Pressed Direction Pad Up (value: 0.000, pressed: 0) isPressed=false isTouched=false I could use for detection Direction Pad Left/Right/Up/Down and detect position between -0.7 and +0.7 and handle it as center button press, because I use that on old Siri remote where I need to distinguish center button and arrows (for switching TV channels by Up/Down and Skip forward/back by Left/Right arrows), but for new Siri remote it would be unnecessary workaround. Does anybody know why the center/select button is not detected when VoiceOver is ON. Is there another way of detecting it using GCController? I don't want to use SwiftUI onTapGesture for this one particular case. Is it an unexpected bug in tvOS APIs or is there some specific reason why center button is not handled by GCController when VoiceOver is ON? Thanks.

Hello, When I listen to title in my app with VoiceOver, it makes a strange sound. This characters make with Korean+number+Alphabet. Is this combination makes some strange sound with voice over? I would like to ask if Apple can fix this issue. Thank you.

I need to direct text-to-speech generated audio from my app simultaneously to a bluetooth speaker device AND to the internal iPad speaker. The app uses AVSpeechSynthesizer and several third party speech engines. How best to do this? I noticed the outputChannels property on AVSpeechSynthesizer...are there any examples of how to use this?

I’m trying to add the .header accessibility trait to a UISegmentedControl so that VoiceOver recognizes it accordingly. However, setting the trait using the following code doesn’t seem to have any effect: segmentControl.accessibilityTraits = segmentControl.accessibilityTraits.union(.header) Even after applying this, VoiceOver doesn’t announce it as a header. Is there any workaround or recommended approach to achieve this?

I have a product for designing particle emitters, which I suspect may be of limited interest to people with limited vision. I'd still like to ensure I'm doing a good job with VoiceOver mode. There's a related, simplified sample online, if you want to look at the code As you can see from the picture below, a large part of the interface mimics Xcode's particle editor, with many value entry controls that combine up/down buttons with a tappable label. Tapping the label goes into edit mode. Apart from changing how labels are stepped through in voiceover in my app, how should I handle these stepper buttons? Is this a good place to use a Custom Rotor?

Merhaba , bir apple mağaza kurulumu yaptık fakat yaptığımız ödemenin faturası henüz gelmedi. Faturaya nereden ulaşacağım hakkında bilgi verebilir misiniz?

In SwiftUI, the date picker component is breaking in colour contrast accessibility. Below code has been use to create date picker: struct ContentView: View { @State private var date = Date() @State private var selectedDate: Date = .init() var body: some View { let min = Calendar.current.date(byAdding: .day, value: 14, to: Date()) ?? Date() let max = Calendar.current.date(byAdding: .year, value: 4, to: Date()) ?? Date() DatePicker( "Start Date", selection: $date, in: min ... max, displayedComponents: [.date] ) .datePickerStyle(.graphical) .frame(alignment: .topLeading) .onAppear { selectedDate = Calendar.current.date(byAdding: .day, value: 14, to: Date()) ?? Date() } } } #Preview { ContentView() } attaching the screenshot of failure accessibility.

I am trying to grant Input Monitoring permission using MDM (Mobile Device Management), but I am facing issues. While I am able to deny the permission, I am unable to grant it. In some profile configurator tools, I noticed a note stating: "Allows the application to use CoreGraphics and HID APIs to listen to (receive) CGEvents and HID events from all processes. Access to these events cannot be given in a profile; it can only be denied." This seems to suggest that granting Input Monitoring permission via an MDM profile may not be possible. Has anyone successfully granted Input Monitoring permission using MDM, or is there an alternative way to achieve this on managed macOS devices?

At present, in iOS, if using the in-house app, there may be crashes in the new iOS 18.3 and later versions, but it works normally on other phones and the certificate is not problematic. A total of 3 machines were found, and there was no pattern between the machines and the system, with different models and versions. We tested it on a machine that crashes, but the app downloaded from the store doesn't. If the same app is packaged and installed directly in the development tool, it will crash. Is this related to compatibility with the new version of IOS? Is there a solution? Do others also have relevant situations?

After replacing Big Sur OSX 11.0 with the latest 11.5, my app's AXObserverAddNotification methods fails. Here is sample code I tested from StackOverflow: https://stackoverflow.com/questions/853833/how-can-my-app-detect-a-change-to-another-apps-window AXUIElementRef app = AXUIElementCreateApplication(82695); // the pid for front-running Xcode 12.5.1 CFTypeRef frontWindow = NULL; AXError err = AXUIElementCopyAttributeValue( app, kAXFocusedWindowAttribute, &frontWindow );     if ( err != kAXErrorSuccess ){         NSLog(@"failed with error: %i",err);     } NSLog(@"app: %@  frontWindow: %@",app,frontWindow); 'frontWindow' reference is never created and I get the error number -25204. It seems like the latest Big Sur 11.5 has revised the Accessibility API or perhaps there is some permission switch I am unaware of that would make things work. What am I doing wrong?

I use AttributedString to create a string containing a link. And I set the AttributedString to UILabel. How should I set up the Accessibility feature to make sure that I can keyboard focus on the substring with link and use keyboard operation to open the link I can VoiceOver the whole string and VoiceOver the substring with link to open the link Thanks a lot.

Watched videos, blog post and downloaded their projects and there the core spot lights works accordingly. I copied code to an empty project and did the same as what they did but still is not working os: macOS and iOS on coredataobject I settled up a attribute to index for spotlight and in object it self I putted the attribute name in display name for spotlight. static let shared = PersistenceController() var spotlightDelegate: NSCoreDataCoreSpotlightDelegate? @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) let viewContext = result.container.viewContext for _ in 0..<10 { let newItem = Item(context: viewContext) newItem.timestamp = Date() } do { try viewContext.save() } catch { let nsError = error as NSError fatalError("Unresolved error \(nsError), \(nsError.userInfo)") } return result }() let container: NSPersistentContainer init(inMemory: Bool = false) { container = NSPersistentContainer(name: "SpotLightSearchTest") if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: "/dev/null") } container.loadPersistentStores(completionHandler: { [weak self] (storeDescription, error) in if let error = error as NSError? { fatalError("Unresolved error \(error), \(error.userInfo)") } if let description = self?.container.persistentStoreDescriptions.first { description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.type = NSSQLiteStoreType if let coordinator = self?.container.persistentStoreCoordinator { self?.spotlightDelegate = NSCoreDataCoreSpotlightDelegate( forStoreWith: description, coordinator: coordinator ) self?.spotlightDelegate?.startSpotlightIndexing() } } }) container.viewContext.automaticallyMergesChangesFromParent = true } } in my @main view struct SpotLightSearchTestApp: App { let persistenceController = PersistenceController.shared var body: some Scene { WindowGroup { ContentView() .environment(\.managedObjectContext, persistenceController.container.viewContext) .onContinueUserActivity(CSSearchableItemActionType) {_ in print("") } } } } onContinueUserActivity(CSSearchableItemActionType) {_ in print("") } never gets triggered. Sow What am I missing that they dont explain in the blog post or videos ?

Good day! I have a long-term project ported all the way up from old Think C through many versions of Xcode. Its source files are encoded in "Western (Mac OS Roman)". Some of my error messages have characters outside the straight ASCII character set (i.e. "å"). The editor correctly displays these, but I get plenty of Illegal Character warnings and the messages do not display properly. I imagine there's a way to have seperate files of localized text for internationalized applications, but I am the only end-user of this application, and it used to just plain work in earlier Xcode versions. Furthermore, there must be developers throughout Europe who use such characters in string literals, just typing in their native languages, straight off their keyboards. I was thinking that there must be a Clang setting or something, but have been unable to find it, and an internet search turns up no solution except to cumbersomely escape each individual character. I can't imagine that a French programmer does that every time they want to type "è", "é", or "à"! Any help? (Disclaimer: I'm an English speaker and only use such characters whimsically, but want to keep them for legacy's sake.) Thanks.... p.s. using Xcode 15.3, and under Settings->Text Editing->Editing, "Western (Mac OS Roman)" is already selected as the default text encoding with "Convert existing files on save" checked.

While editing the search text using the external keyboard (with VoiceOver on), if I try to navigate the to List using the keyboard, the focus jumps back to the search field immediately, preventing selection of list items. It's important to note that the voiceover navigation alone without a keyboard works as expected. It’s as if the List never gains focus—every attempt to move focus lands back on the search field. The code: struct ContentView: View { @State var searchText = "" let items = ["Apple", "Banana", "Cherry", "Date", "Elderberry", "Fig", "Grape"] var filteredItems: [String] { if searchText.isEmpty { return items } else { return items.filter { $0.localizedCaseInsensitiveContains(searchText) } } } var body: some View { if #available(iOS 16.0, *) { NavigationStack { List(filteredItems, id: \.self) { item in Text(item) } .navigationTitle("Fruits") .searchable(text: $searchText) } } else { NavigationView { List(filteredItems, id: \.self) { item in Text(item) } .navigationTitle("Fruits") .searchable(text: $searchText) } } } }

I am seeing a strange issue where NSObject accessibilityRespondsToUserInteraction returns true on Simulator but false on device. Checking the same object on simulator with Accessibility inspector I see the object traits as image so why would it return true in that case? Are there any other way to check the the item might be accessibilityRespondsToUserInteraction OR Clickable beside that property and traits? (Or is it just another bug)