Explore best practices for creating inclusive apps for users of Apple accessibility features and users from diverse backgrounds.

All subtopics
Posts under Accessibility & Inclusion topic

Post

Replies

Boosts

Views

Activity

input type="number" not mapped to spinbutton role
input[type=number] mapped to AXTextField instead of AXIncrementor/UIAccessibilityTraitAdjustable in Safari (macOS and iOS). According to ML-AAM 1.0, <input type="number"> is required to map to the ARIA spinbutton role, but it is not being mapped as expected on WebKit (macOS and iOS) to the platform accessibility APIs: the element is reported as AXTextField on macOS and lacks UIAccessibilityTraitAdjustable on iOS. As a consequence, VoiceOver announces the element as a textfield rather than a spinbutton, does not increment with arrow keys on macOS, and does not respond to the swipe up/down gesture on iOS. This affects every <input type="number"> on the web (quantity steppers, age inputs, year pickers, etc). Authors are currently forced to work around it by reimplementing the spinbutton with role="spinbutton", which force the authors to emulate the native HTML solutions with JavaScript, contradicts the First Rule of ARIA Use and presents another interaction issues in WebKit (will create an issue about this and update this post later). References: HTML-AAM 1.0, input type=number: https://www.w3.org/TR/html-aam-1.0/#el-input-number ARIA 1.2, spinbutton role: https://www.w3.org/TR/wai-aria-1.2/#spinbutton First Rule of ARIA Use: https://www.w3.org/TR/using-aria/#firstrule Reproduction: https://codesandbox.io/p/sandbox/beautiful-hofstadter-vn7nj3 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>spinbutton techniques</title> </head> <body> <main> <h1>Spinbutton pattern</h1> <section aria-labelledby="html-solution"> <h2 id="html-solution">HTML solution: spinbutton</h2> <label for="qty">Quantity</label> <input id="qty" type="number" min="0" max="10" value="1" /> </section> </main> </body> </html> Expected behavior: AX role on macOS: AXIncrementor (mapped from spinbutton) AX trait on iOS: UIAccessibilityTraitAdjustable VoiceOver on macOS announces "[value], [name of the input], stepper" and then "you are currently on a stepper. To begin interacting with this stepper, press Control-Shift-Down Arrow", after pressing the combo should announce "in stepper" and inmmediately should announce "you are currently in a stepper. To decrease this value, press Control-Option-Down Arrow. To increase this value, press Control-Option-Up Arrow. to exit this stepper, press Control-Option-Shift-Up Arrow" One-finger swipe up/down on iOS increments/decrements the value Actual behavior on Safari: AX role on macOS: AXTextField AX trait on iOS: standard textfield, no Adjustable VoiceOver announces "[value], insertion at the beginning/end of the text, [name of the input], number field" and then "you are currently on text field. To enter text in this field, type". Omitting the native functionality of a spinbutton One-finger swipe up/down on iOS does nothing Cross-platform comparison (same HTML, same spec): Firefox + NVDA on Windows: Chrome + NVDA on Windows: same as Firefox Safari + VoiceOver on macOS: broken as described above Safari + VoiceOver on iOS: broken as described above Environment: macOS: maOS Tahoe 26.4.1 Safari: 26.4 (21624.1.16.11.4) iOS: iOS 26.4.2 Device: iPhone 15 VoiceOver: default settings
0
0
163
1d
iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
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!
17
4
5.5k
2d
ImageRenderer fails to render Text views that use @AccessibilityFocusState (.accessibilityFocused)
Environment: iOS 16.0+ SwiftUI Problem Description: I am using ImageRenderer to convert a SwiftUI view into a UIImage for sharing purposes. The view renders perfectly fine on-screen. However, in the generated UIImage, specific Text elements completely disappear. After debugging, I found that the issue is caused by the @AccessibilityFocusState property wrapper. Any Text view that has the .accessibilityFocused(_:) modifier applied to it will be completely missing from the ImageRenderer output. Other views (like Text without the modifier, or Image views) in the exact same hierarchy render perfectly. It seems that because ImageRenderer renders the view off-screen without a live accessibility environment/tree, the accessibility focus binding silently breaks the layout or rendering of that specific element. Minimal Reproducible Example: Here is a generic, drop-in example that demonstrates the bug. When you tap "Capture with ImageRenderer", the resulting image will only contain the subtitle, while the title text vanishes. import SwiftUI // 1. The View we want to render struct ComponentView: View { // The accessibility focus state causing the issue @AccessibilityFocusState private var isTitleFocused: Bool var body: some View { VStack(spacing: 12) { // BUG: This text will NOT appear in the rendered image Text("Title (with accessibility focus)") .font(.headline) .accessibilityFocused($isTitleFocused) // This text WILL appear normally Text("Subtitle (no accessibility focus)") .font(.subheadline) } .padding() .background(Color.blue.opacity(0.1)) .cornerRadius(12) } } // 2. The Container to test the rendering struct ContentView: View { @State private var renderedImage: UIImage? var body: some View { VStack(spacing: 40) { // On-screen: Both Title and Subtitle appear perfectly VStack { Text("Live On-Screen View:") .font(.caption) ComponentView() } Button("Capture with ImageRenderer") { renderImage() } .buttonStyle(.borderedProminent) // Off-screen render: Title is missing! if let image = renderedImage { VStack { Text("Rendered UIImage Result:") .font(.caption) Image(uiImage: image) .overlay( Rectangle().stroke(Color.red, style: StrokeStyle(lineWidth: 1, dash: [5])) ) } } } .padding() } @MainActor private func renderImage() { let renderer = ImageRenderer(content: ComponentView()) renderer.scale = UIScreen.main.scale if let uiImage = renderer.uiImage { self.renderedImage = uiImage } } } Questions: Is this a known limitation of ImageRenderer not supporting the accessibility environment? Is there a way to inject an accessibility environment into ImageRenderer so these modifiers don't break the render? Are there any cleaner workarounds other than manually stripping accessibility modifiers before rendering?
2
0
630
4d
Full Keyboard Access Health app close button not accessible
I found difficulty interacting with close button on placement inside Health app on newest iOS. Steps to reproduce: Open Health app Scroll to "Get more from health" Try to focus on close button on any box like "Set Up your medical ID" Focus is on the whole box and there is now way to move to close button. After hitting space it opens next screen. Solving this issue might help with similar issue in our app.
1
0
574
5d
Full Keyboard Access Reminders app inaccessible content
When using Full Keyboard Access some content in Reminders app is not accessible. Steps to reproduce: Open Reminders app Open one of the lists with few (ex. 4) records. Try to check reminder. Issue: Navigating with keyboard focuses on whole row, using arrows left/right doesn't move to check control. Using space on whole row activates textfield, then still left/right arrow does not move outside textfield. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard. Solving this issue might help with similar issues in our app.
0
0
126
5d
Full Keyboard Access Photos app scroll view is not accessible
When using Full Keyboard Access on iPhone in Photos app some interactive content is not available to enter. Steps to reproduce: Open Photos app Go to Collections tab Go to memories Try to select any memory playlist Whole scroll view is selectable as one element and using space is not making any difference. Using tab goes to navigation controls. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard.
0
0
97
5d
Full Keyboard Access Photos app Information button not selectable
When Full Keyboard Access is enabled, some controls in the Photos app appear to be unreachable using keyboard navigation. Steps to reproduce: Enable Full Keyboard Access. Open the Photos app. Navigate to the Collections tab. Use arrow keys to move focus through the screen. The Info (“i”) button related to library optimization is not reachable. When focus is on the left side (e.g. “Reorder”), pressing the down arrow moves focus directly to the tab bar. When focus is on the right side (e.g. the chevron next to “Wallpaper Suggestions”), focus moves directly to the Search button. The Info button is skipped in both cases. Tested on simulator iPhone 17 Pro with iOS 26.2.
0
0
48
6d
Accessibility Inspector Bugs
Hello, i'm currently working on improving accessibility in my app using the built-in Xcode tool, Accessibility Inspector. For the most part, it works well — it correctly displays warnings about missing button labels or insufficient touch target sizes. However, it does not seem to handle certain cases properly, particularly dynamic fonts. Here is the approach I’m using for dynamic fonts: static func getDynamic(font: FontType, size: CGFloat, textStyle: UIFont.TextStyle) -> UIFont { let customFont = UIFont(name: font.rawValue, size: size)! return UIFontMetrics(forTextStyle: textStyle).scaledFont(for: customFont) } label.adjustsFontForContentSizeCategory = true My labels are configured with: numberOfLines = 0 no fixed height constraints This allows them to expand as needed without clipping. I have tested this visually on multiple devices, and everything appears to work correctly — fonts scale as expected, and text is not truncated. However, Accessibility Inspector still reports issues related to dynamic type and, in some cases, text clipping. On iOS 18, approximately 40% of the fonts configured this way still trigger warnings about missing dynamic type support, even though they scale correctly. On iOS 26+, the issue becomes consistent — every font in the app triggers this warning. There are no cases where the inspector passes without reporting a problem, despite the UI behaving correctly in practice. So my question is: Is there a known way to resolve this? Could this be an issue with Apple's tools? If so, is there any information on when it might be fixed?
1
1
1.7k
1w
VoiceOver is interrupted/disabled when running XCUITest (WDA). Request guidance for accessibility research automation on iOS.
Hello, I am working on a research project focused on creating accessible interactions for visually impaired users. I need to verify some automated assistance processes in a real-world usage environment where VoiceOver is enabled. However, I have encountered a blocking issue: When I connect the device through Xcode UI Test / WebDriverAgent (or Appium + WDA) and perform operations, VoiceOver gets interrupted (sometimes it is even directly turned off), preventing blind users from continuing to use the narrator. Replication steps (stable replication)    On iPhone, enable VoiceOver (Settings → Accessibility → Narrator), and keep the device unlocked and the screen on. On Mac, start [Xcode UI Test / WebDriverAgentRunner / Appium+WDA] and establish a session with the device (XCTest session). Perform any operation: read the accessibility tree (/source), take screenshots, or click/slide. Observe the phenomenon: VoiceOver will [automatically turn off / reading interruption / focus jumping / unable to continue reading the new interface]. Expected behavior VoiceOver, as the core accessibility capability, should remain running and be able to continue reading the interface; the automation/assistance process should not "steal" and cause the narrator to fail. Actual behavior VoiceOver is [turned off / interrupted], and even after interface changes, it cannot read normally, affecting the use of blind users. I would like to ask: Non-jailbroken or external hardware-free methods Is this a known limitation (such as the mutual exclusion between XCTest and VoiceOver as Accessibility clients)? Is there an officially supported way to allow the automation/assistance program to safely read necessary information and trigger operations while VoiceOver is enabled, without disrupting the narrator (such as App Intents, Shortcuts, or other API/framework suggestions)? If it is necessary to avoid XCTest/WDA: In the research prototype stage, what is the recommended "reproducible, measurable" alternative technical route?
1
0
1.8k
3w
actionGroupCell Y coordinates are corrupted. The overlay for 'Save to Files' doesn't expose no valid id's for testability.
I am using Maestro framework for testing iOS. For our tests we need to save pdf's to files. When opening the 'QLOverlayDefaultActionButtonAccessibilityIdentifier' the buttons on the overlay are way off, the coordinates got corrupted. When opening the files app, the next screen has no coordinates for testing. I checked with xcode inspector and the same issue persists.
1
0
457
3w
Left-flick and right-flick gestures with VoiceOver and UIAccessibilityReadingContent
Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.
1
0
1.4k
Apr ’26
AXSpeech Thread Crash SEGV_ACCERR
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!
7
0
2.3k
Mar ’26
Please, Apple. I am begging you. Fix the broken Text-To-Speech in macOS
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!
9
2
2.8k
Mar ’26
Apple Pay e installazione di app di terze parti non funzionanti
Scrivo questo post per farmi notare meglio, il 6 marzo ho mandato un feedback (poi aggiornato oggi, 18 marzo) tramite l‘app Feedback installata su iPhone chiedo a chiunque lavori all’interno di Apple, specialmente agli ingegneri informatici che si occupano delle funzioni di accessibilità di iOS 26 di visionare questo Feedback per aumentare ancora di più le opzioni di accessibilità degli utenti Apple, vi lascio di seguito l’ID del Feedback, grazie mille per il lavoro che fate FB22142615
1
0
618
Mar ’26
Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context
I occasionally get this error in Xcode’s console: Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context. What does this mean, and how can I resolve it? Googling it doesn’t turn up any results. This doesn't crash the app - it’s just an error diagnostic that I see in the Xcode console. The app keeps running before and after the issue. Is there a way I can set a breakpoint to catch this where it happens?
9
2
3.7k
Mar ’26
ScrollView hicjacking focus in swiftui
Greetings! I'm facing a problem handleling full keyboard access in my app. This is a simpler version of the code: struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } .navigationTitle("Title n stuff") .padding() } } And the focus behaves as expected and the important thing, we can access que button on the right side of the screen But as soon as we introduce the scrollview, the right side button is unaccessible, since when we hit tab we go back to the back button in the nav stack header. struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { ScrollView { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } } .navigationTitle("Title n stuff") .padding() } } I've tried all the things I found online and none achieves an acceptable behavoir, I've seen ppl saying this issue has been fixed in ipados with the focusSection modifier, but I have not seen any fix fot this issue in ios.
1
0
970
Mar ’26
iOS 26: Tab Bar Item's accessibility value not set automatically anymore
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.
3
1
1.3k
Mar ’26
API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again.
API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again. i don't see any pending license agreement in the business section
Replies
0
Boosts
0
Views
10
Activity
1h
Family Control Distribution
It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?
Replies
0
Boosts
0
Views
8
Activity
1h
input type="number" not mapped to spinbutton role
input[type=number] mapped to AXTextField instead of AXIncrementor/UIAccessibilityTraitAdjustable in Safari (macOS and iOS). According to ML-AAM 1.0, <input type="number"> is required to map to the ARIA spinbutton role, but it is not being mapped as expected on WebKit (macOS and iOS) to the platform accessibility APIs: the element is reported as AXTextField on macOS and lacks UIAccessibilityTraitAdjustable on iOS. As a consequence, VoiceOver announces the element as a textfield rather than a spinbutton, does not increment with arrow keys on macOS, and does not respond to the swipe up/down gesture on iOS. This affects every <input type="number"> on the web (quantity steppers, age inputs, year pickers, etc). Authors are currently forced to work around it by reimplementing the spinbutton with role="spinbutton", which force the authors to emulate the native HTML solutions with JavaScript, contradicts the First Rule of ARIA Use and presents another interaction issues in WebKit (will create an issue about this and update this post later). References: HTML-AAM 1.0, input type=number: https://www.w3.org/TR/html-aam-1.0/#el-input-number ARIA 1.2, spinbutton role: https://www.w3.org/TR/wai-aria-1.2/#spinbutton First Rule of ARIA Use: https://www.w3.org/TR/using-aria/#firstrule Reproduction: https://codesandbox.io/p/sandbox/beautiful-hofstadter-vn7nj3 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8" /> <title>spinbutton techniques</title> </head> <body> <main> <h1>Spinbutton pattern</h1> <section aria-labelledby="html-solution"> <h2 id="html-solution">HTML solution: spinbutton</h2> <label for="qty">Quantity</label> <input id="qty" type="number" min="0" max="10" value="1" /> </section> </main> </body> </html> Expected behavior: AX role on macOS: AXIncrementor (mapped from spinbutton) AX trait on iOS: UIAccessibilityTraitAdjustable VoiceOver on macOS announces "[value], [name of the input], stepper" and then "you are currently on a stepper. To begin interacting with this stepper, press Control-Shift-Down Arrow", after pressing the combo should announce "in stepper" and inmmediately should announce "you are currently in a stepper. To decrease this value, press Control-Option-Down Arrow. To increase this value, press Control-Option-Up Arrow. to exit this stepper, press Control-Option-Shift-Up Arrow" One-finger swipe up/down on iOS increments/decrements the value Actual behavior on Safari: AX role on macOS: AXTextField AX trait on iOS: standard textfield, no Adjustable VoiceOver announces "[value], insertion at the beginning/end of the text, [name of the input], number field" and then "you are currently on text field. To enter text in this field, type". Omitting the native functionality of a spinbutton One-finger swipe up/down on iOS does nothing Cross-platform comparison (same HTML, same spec): Firefox + NVDA on Windows: Chrome + NVDA on Windows: same as Firefox Safari + VoiceOver on macOS: broken as described above Safari + VoiceOver on iOS: broken as described above Environment: macOS: maOS Tahoe 26.4.1 Safari: 26.4 (21624.1.16.11.4) iOS: iOS 26.4.2 Device: iPhone 15 VoiceOver: default settings
Replies
0
Boosts
0
Views
163
Activity
1d
iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
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!
Replies
17
Boosts
4
Views
5.5k
Activity
2d
ImageRenderer fails to render Text views that use @AccessibilityFocusState (.accessibilityFocused)
Environment: iOS 16.0+ SwiftUI Problem Description: I am using ImageRenderer to convert a SwiftUI view into a UIImage for sharing purposes. The view renders perfectly fine on-screen. However, in the generated UIImage, specific Text elements completely disappear. After debugging, I found that the issue is caused by the @AccessibilityFocusState property wrapper. Any Text view that has the .accessibilityFocused(_:) modifier applied to it will be completely missing from the ImageRenderer output. Other views (like Text without the modifier, or Image views) in the exact same hierarchy render perfectly. It seems that because ImageRenderer renders the view off-screen without a live accessibility environment/tree, the accessibility focus binding silently breaks the layout or rendering of that specific element. Minimal Reproducible Example: Here is a generic, drop-in example that demonstrates the bug. When you tap "Capture with ImageRenderer", the resulting image will only contain the subtitle, while the title text vanishes. import SwiftUI // 1. The View we want to render struct ComponentView: View { // The accessibility focus state causing the issue @AccessibilityFocusState private var isTitleFocused: Bool var body: some View { VStack(spacing: 12) { // BUG: This text will NOT appear in the rendered image Text("Title (with accessibility focus)") .font(.headline) .accessibilityFocused($isTitleFocused) // This text WILL appear normally Text("Subtitle (no accessibility focus)") .font(.subheadline) } .padding() .background(Color.blue.opacity(0.1)) .cornerRadius(12) } } // 2. The Container to test the rendering struct ContentView: View { @State private var renderedImage: UIImage? var body: some View { VStack(spacing: 40) { // On-screen: Both Title and Subtitle appear perfectly VStack { Text("Live On-Screen View:") .font(.caption) ComponentView() } Button("Capture with ImageRenderer") { renderImage() } .buttonStyle(.borderedProminent) // Off-screen render: Title is missing! if let image = renderedImage { VStack { Text("Rendered UIImage Result:") .font(.caption) Image(uiImage: image) .overlay( Rectangle().stroke(Color.red, style: StrokeStyle(lineWidth: 1, dash: [5])) ) } } } .padding() } @MainActor private func renderImage() { let renderer = ImageRenderer(content: ComponentView()) renderer.scale = UIScreen.main.scale if let uiImage = renderer.uiImage { self.renderedImage = uiImage } } } Questions: Is this a known limitation of ImageRenderer not supporting the accessibility environment? Is there a way to inject an accessibility environment into ImageRenderer so these modifiers don't break the render? Are there any cleaner workarounds other than manually stripping accessibility modifiers before rendering?
Replies
2
Boosts
0
Views
630
Activity
4d
Full Keyboard Access Health app close button not accessible
I found difficulty interacting with close button on placement inside Health app on newest iOS. Steps to reproduce: Open Health app Scroll to "Get more from health" Try to focus on close button on any box like "Set Up your medical ID" Focus is on the whole box and there is now way to move to close button. After hitting space it opens next screen. Solving this issue might help with similar issue in our app.
Replies
1
Boosts
0
Views
574
Activity
5d
Full Keyboard Access Reminders app inaccessible content
When using Full Keyboard Access some content in Reminders app is not accessible. Steps to reproduce: Open Reminders app Open one of the lists with few (ex. 4) records. Try to check reminder. Issue: Navigating with keyboard focuses on whole row, using arrows left/right doesn't move to check control. Using space on whole row activates textfield, then still left/right arrow does not move outside textfield. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard. Solving this issue might help with similar issues in our app.
Replies
0
Boosts
0
Views
126
Activity
5d
Full Keyboard Access Photos app scroll view is not accessible
When using Full Keyboard Access on iPhone in Photos app some interactive content is not available to enter. Steps to reproduce: Open Photos app Go to Collections tab Go to memories Try to select any memory playlist Whole scroll view is selectable as one element and using space is not making any difference. Using tab goes to navigation controls. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard.
Replies
0
Boosts
0
Views
97
Activity
5d
Full Keyboard Access Photos app Information button not selectable
When Full Keyboard Access is enabled, some controls in the Photos app appear to be unreachable using keyboard navigation. Steps to reproduce: Enable Full Keyboard Access. Open the Photos app. Navigate to the Collections tab. Use arrow keys to move focus through the screen. The Info (“i”) button related to library optimization is not reachable. When focus is on the left side (e.g. “Reorder”), pressing the down arrow moves focus directly to the tab bar. When focus is on the right side (e.g. the chevron next to “Wallpaper Suggestions”), focus moves directly to the Search button. The Info button is skipped in both cases. Tested on simulator iPhone 17 Pro with iOS 26.2.
Replies
0
Boosts
0
Views
48
Activity
6d
Accessibility Inspector Bugs
Hello, i'm currently working on improving accessibility in my app using the built-in Xcode tool, Accessibility Inspector. For the most part, it works well — it correctly displays warnings about missing button labels or insufficient touch target sizes. However, it does not seem to handle certain cases properly, particularly dynamic fonts. Here is the approach I’m using for dynamic fonts: static func getDynamic(font: FontType, size: CGFloat, textStyle: UIFont.TextStyle) -> UIFont { let customFont = UIFont(name: font.rawValue, size: size)! return UIFontMetrics(forTextStyle: textStyle).scaledFont(for: customFont) } label.adjustsFontForContentSizeCategory = true My labels are configured with: numberOfLines = 0 no fixed height constraints This allows them to expand as needed without clipping. I have tested this visually on multiple devices, and everything appears to work correctly — fonts scale as expected, and text is not truncated. However, Accessibility Inspector still reports issues related to dynamic type and, in some cases, text clipping. On iOS 18, approximately 40% of the fonts configured this way still trigger warnings about missing dynamic type support, even though they scale correctly. On iOS 26+, the issue becomes consistent — every font in the app triggers this warning. There are no cases where the inspector passes without reporting a problem, despite the UI behaving correctly in practice. So my question is: Is there a known way to resolve this? Could this be an issue with Apple's tools? If so, is there any information on when it might be fixed?
Replies
1
Boosts
1
Views
1.7k
Activity
1w
VoiceOver is interrupted/disabled when running XCUITest (WDA). Request guidance for accessibility research automation on iOS.
Hello, I am working on a research project focused on creating accessible interactions for visually impaired users. I need to verify some automated assistance processes in a real-world usage environment where VoiceOver is enabled. However, I have encountered a blocking issue: When I connect the device through Xcode UI Test / WebDriverAgent (or Appium + WDA) and perform operations, VoiceOver gets interrupted (sometimes it is even directly turned off), preventing blind users from continuing to use the narrator. Replication steps (stable replication)    On iPhone, enable VoiceOver (Settings → Accessibility → Narrator), and keep the device unlocked and the screen on. On Mac, start [Xcode UI Test / WebDriverAgentRunner / Appium+WDA] and establish a session with the device (XCTest session). Perform any operation: read the accessibility tree (/source), take screenshots, or click/slide. Observe the phenomenon: VoiceOver will [automatically turn off / reading interruption / focus jumping / unable to continue reading the new interface]. Expected behavior VoiceOver, as the core accessibility capability, should remain running and be able to continue reading the interface; the automation/assistance process should not "steal" and cause the narrator to fail. Actual behavior VoiceOver is [turned off / interrupted], and even after interface changes, it cannot read normally, affecting the use of blind users. I would like to ask: Non-jailbroken or external hardware-free methods Is this a known limitation (such as the mutual exclusion between XCTest and VoiceOver as Accessibility clients)? Is there an officially supported way to allow the automation/assistance program to safely read necessary information and trigger operations while VoiceOver is enabled, without disrupting the narrator (such as App Intents, Shortcuts, or other API/framework suggestions)? If it is necessary to avoid XCTest/WDA: In the research prototype stage, what is the recommended "reproducible, measurable" alternative technical route?
Replies
1
Boosts
0
Views
1.8k
Activity
3w
actionGroupCell Y coordinates are corrupted. The overlay for 'Save to Files' doesn't expose no valid id's for testability.
I am using Maestro framework for testing iOS. For our tests we need to save pdf's to files. When opening the 'QLOverlayDefaultActionButtonAccessibilityIdentifier' the buttons on the overlay are way off, the coordinates got corrupted. When opening the files app, the next screen has no coordinates for testing. I checked with xcode inspector and the same issue persists.
Replies
1
Boosts
0
Views
457
Activity
3w
Left-flick and right-flick gestures with VoiceOver and UIAccessibilityReadingContent
Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.
Replies
1
Boosts
0
Views
1.4k
Activity
Apr ’26
Display Zoom
Looking to begin an accessibility vision app and I’m not having any luck locating properties or code that allows access to the display zoom. Has anyone worked with these areas before?
Replies
1
Boosts
1
Views
2.8k
Activity
Mar ’26
AXSpeech Thread Crash SEGV_ACCERR
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!
Replies
7
Boosts
0
Views
2.3k
Activity
Mar ’26
Please, Apple. I am begging you. Fix the broken Text-To-Speech in macOS
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!
Replies
9
Boosts
2
Views
2.8k
Activity
Mar ’26
Apple Pay e installazione di app di terze parti non funzionanti
Scrivo questo post per farmi notare meglio, il 6 marzo ho mandato un feedback (poi aggiornato oggi, 18 marzo) tramite l‘app Feedback installata su iPhone chiedo a chiunque lavori all’interno di Apple, specialmente agli ingegneri informatici che si occupano delle funzioni di accessibilità di iOS 26 di visionare questo Feedback per aumentare ancora di più le opzioni di accessibilità degli utenti Apple, vi lascio di seguito l’ID del Feedback, grazie mille per il lavoro che fate FB22142615
Replies
1
Boosts
0
Views
618
Activity
Mar ’26
Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context
I occasionally get this error in Xcode’s console: Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context. What does this mean, and how can I resolve it? Googling it doesn’t turn up any results. This doesn't crash the app - it’s just an error diagnostic that I see in the Xcode console. The app keeps running before and after the issue. Is there a way I can set a breakpoint to catch this where it happens?
Replies
9
Boosts
2
Views
3.7k
Activity
Mar ’26
ScrollView hicjacking focus in swiftui
Greetings! I'm facing a problem handleling full keyboard access in my app. This is a simpler version of the code: struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } .navigationTitle("Title n stuff") .padding() } } And the focus behaves as expected and the important thing, we can access que button on the right side of the screen But as soon as we introduce the scrollview, the right side button is unaccessible, since when we hit tab we go back to the back button in the nav stack header. struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { ScrollView { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } } .navigationTitle("Title n stuff") .padding() } } I've tried all the things I found online and none achieves an acceptable behavoir, I've seen ppl saying this issue has been fixed in ipados with the focusSection modifier, but I have not seen any fix fot this issue in ios.
Replies
1
Boosts
0
Views
970
Activity
Mar ’26
iOS 26: Tab Bar Item's accessibility value not set automatically anymore
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.
Replies
3
Boosts
1
Views
1.3k
Activity
Mar ’26