Hello, Whenever I put accessibility focus on an image and if image has some text in it, voiceover reads that text along with image's accessibility label. Is there a way to programmatically turn off text recognition on images for accessibility? I couldn't find any relevant accessibility API's that could help here. Thanks!

We use an embedded WKWebView for several screens in our app. Recently, we have been testing keyboard navigation via Full Keyboard Access in our apps. On IOS 18, everything works pretty much as expected. On IOS 26, it does not. On IOS 26, you can "tab" away from the webview and then never tab back to the webview for keyboard navigation. Is this a known issue? Are there workarounds for this issue that anyone is aware of?

System settings => Accessibility => System Voice => the little (i) beside the pulldown => Voices => THIS SCREEN will allow you to download Premium Voices Is there a way to trigger this screen programmatically. Or at least a link to get my users there without having to dig thru that swamp of screens?

Hello! I was doing some accessibility testing for my app and found out that when the user switches the text size, all of the data in the text fields is reset, which causes major disruption. I've tried looking for documentation, but all I've found is information on how to dynamically scale the UI for different text sizes, which I've already implemented. My guess is that every time Dynamic Type registers a change, it redraws my UI instead of just updating it. How can I make sure the data is not reset when the text size changes?

Hey, We've run into an issue where WKWebView contents are not always available for VoiceOver users. It seems to occur when WKWebView contents are loaded asynchronously. I have a sample project where this can be reproduced and a video showing the issue. See FB21257352 The only solution we currently see is forcing an update continuously using UIAccessibility.post(notification: .layoutChanged, argument: nil), but this is ofc a last resort as it may have other unintended side effects.

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).

I have an app that needs Input Monitoring permissions to get keyboard access in the background. I've attempted to use both IOHIDCheckAccess(kIOHIDRequestTypeListenEvent) and IOHIDRequestAccess(kIOHIDRequestTypeListenEvent), but they always return denied, even though I have given the permission for Input Monitoring to the app in Settings. Is there something I need to put in my Info.plist to enable this permission to work?

Hi Community, I'm excited to share R Helper, a speech practice app I built with accessibility as the core focus from day one. App Store: https://apps.apple.com/app/speak-r-clearly/id6751442522 WHY I BUILT THIS I personally struggled with R sound pronunciation growing up. It affected my confidence in school and job interviews. That experience taught me how important accessible practice tools are. R Helper helps children and adults practice R sounds with full accessibility support. ACCESSIBILITY FEATURES IMPLEMENTED VoiceOver - complete navigation and feedback Voice Control - hands-free operation Dynamic Type - scales to large accessibility sizes Reduce Motion - respects user preference Dark Mode - user controllable High Contrast compatibility Differentiate Without Color THE CHALLENGE Most speech practice apps ignore accessibility. I wanted to change that and prove that specialized educational apps can be fully accessible. KEY FEATURES Works 100% offline, no internet needed Zero data collection, privacy first Generous free tier with all accessibility features included 10 story missions with gamification 7 languages supported including RTL for Arabic LESSONS LEARNED Accessibility is not hard when you prioritize it from the start. VoiceOver labels and hints make a huge difference. Testing with accessibility features enabled is essential. Standard SwiftUI components handle most accessibility automatically. Reducing motion significantly helps users with vestibular issues. TECHNICAL DETAILS Built with SwiftUI, targets iOS 17 and up. Universal app for iPhone and iPad. Fully offline using CoreData and local storage. No third party analytics, privacy focused. QUESTIONS FOR THE COMMUNITY What accessibility features do you find users request most? How do you test accessibility features efficiently? WHATS NEXT I'm currently working on expanding the word library, adding more story content, improving haptic feedback Thanks for reading. Nour

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.

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.

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!

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?

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?

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?

I have already filed a bug report with a sample project via Feedback Assistant: FB22760723 When presenting a UIViewController using UIModalPresentationFormSheet alongside UISheetPresentationController with a small custom detent (e.g., around 300pt height), VoiceOver spatial swipe navigation breaks. The user is unable to swipe left or right to navigate sequentially through the accessible elements inside the sheet. Accessibility Inspector reveals that the focus seems to get trapped by the background layer (UIDimmingView / "dismiss popup"). If the sheet is taller (e.g., 600pt), the issue does not occur and swipe navigation works as expected Steps to Reproduce: Run the attached sample Objective-C/UIKit project. Turn on VoiceOver. Tap the “Open transparent modal” button to present the modal with UIModalPresentationOverFullScreen presentation. Tap the "Open form sheet" button to present the sheet (configured with a custom 300pt detent). Attempt to swipe right using VoiceOver to navigate to the next element (e.g., from the title label to the buttons). Expected Results: VoiceOver should smoothly navigate through the sequential accessibility elements inside the sheet's view hierarchy, respecting the bounds of the modal sheet. Actual Results: VoiceOver gets stuck. The swipe right/left gestures fail to move focus to the next element inside the sheet. Instead, focus often escapes to the background or doesn’t change completely.

If a user enables/disables Guided Access, they can modify the session settings to disable the top (sleep/wake) button. In Single App Mode (SAM), there is a payload option for disabling the sleep/wake button via Mobile Device Management (MDM). In Autonomous Single App Mode (ASAM), there doesn't appear to be any way to disable the top button. ASAM does not honor the Guided Access sessions settings, and there is no payload option in the MDM. This is a glaring issue especially when ASAM is marketed as the solution for apps in a medical setting where the app is trading hands from a medical professional to a patient. Our app is used during a lengthy procedure and does not function properly if the patient puts the iPad to sleep. We're stuck asking our medical professionals to put the iPad in Guided Access, but the user experience is clunky and would be much improved by implementing ASAM. Is there some little-known API for disabling the sleep/wake button during ASAM that I'm just missing?

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

Dictation in German has a couple of persistent bugs. Saying "Anführungszeichen" inserts punctuation AND writes out the word: When dictating the word „Anführungszeichen" in German, the app both inserts quotation marks AND writes out the word literally. Expected: either insert the punctuation OR write the word – not both. Manual quotation mark followed by automatic blank key during dictation. Compound words incorrectly split into separate words: Compound words are either cohesive or hyphenated, the english spelling with two separate words is simply wrong!) Spaces incorrectly added around hyphens in compound words: German dictation adds spaces before and after hyphens. In German orthography, spaces around hyphens are only correct for em dashes (Gedankenstrich), never for regular hyphens in compound words.

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!

Hello everyone, I’d like to report an issue I’ve encountered when using a Bluetooth mouse together with AssistiveTouch on iPhone running iOS 16.5. This has also been reported via Feedback Assistant with Feedback ID: FB17806167 Description: When using a Bluetooth mouse together with AssistiveTouch on iPhone (iOS), the pointer behaves incorrectly in landscape orientation. Specifically: The pointer cannot move past the center of the screen Horizontal and vertical (X/Y) movements appear to be swapped or misaligned Natural movement of the pointer is not possible It seems as if the internal coordinate mapping remains locked in portrait orientation, even when the device is physically rotated to landscape. This issue occurs system-wide, regardless of the current app. It is observable in Settings, on the Home screen, and in third-party apps. Steps to Reproduce: Enable AssistiveTouch Connect a Bluetooth mouse to the iPhone Rotate the device to landscape orientation Try moving the mouse pointer across the screen → Notice that: Pointer cannot move past the center Horizontal/vertical input is interpreted incorrectly (as if still in portrait) Expected Behavior: The mouse pointer should move across the entire screen correctly, regardless of device orientation. Actual Behavior: In landscape orientation, the pointer is either restricted to part of the screen or misaligned. It behaves as if the device is still in portrait. Horizontal mouse movement causes vertical pointer movement, and vice versa User experience feels broken and unintuitive Feature Suggestion: Please improve the synchronization between physical device orientation and AssistiveTouch pointer mapping on iOS. I also suggest exposing AssistiveTouch orientation control via a public API, so developers can help maintain consistent pointer behavior. Thanks in advance for any insights or suggestions. Best regards, Jannis