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.

In our application we are using UITableView for data population and that TableView cell contains a button. When we are enabling full keyboard access that time only TableView cell is focusing not the button. We need to focus on cell and button differently.

In our application we are using a Search bar in a pop over view and we have enabled Accessibility full keyboard access and we are using external keyboard. Now if the focus is on Searcher that time by next Tab key press Search bar will dismiss and focus needs to shift to the next UIElement.

In our application we are using OTP login. When accessibility full keyboard access is enabled, and we are trying to enter OTP in the OTP field that time in iOS 17 focus is moving to the next text field accordingly but in iOS 18 focus is staying the first OTP field only and not moving to the next text field.

In our application we are using UIAlertViewController. When accessibility full keyboard access is enabled, and we are trying to dismiss that AlertViewController with Esc key from external keyboard that is not working. We are presenting AlertViewController as a popover. We need dismiss the AlertViewController with Esc key press from external keyboard.

Hello, the AVSpeechSynthesisVoice has a audioFileSettings attributes let utterance = AVSpeechUtterance(string: text) utterance.voice = AVSpeechSynthesisVoice(identifier: voiceSelected!) print("- voice \(utterance.voice!.audioFileSettings)") ["AVLinearPCMIsBigEndianKey": 0, "AVLinearPCMIsFloatKey": 1, "AVLinearPCMIsNonInterleaved": 1, "AVNumberOfChannelsKey": 1, "AVSampleRateKey": 22050, "AVFormatIDKey": 1819304813, "AVLinearPCMBitDepthKey": 32] This is declared in AVSpeechSynthesisVoice { ... @available(iOS 13.0, *) open var **audioFileSettings:** [String : Any] { get } @available(iOS 17.0, *) open var voiceTraits: AVSpeechSynthesisVoice.Traits { get } } How can we specify the audioFileSettings attributes in a AVSpeechSynthesisProviderVoice ? Cause in AVSpeechSynthesisProviderVoice there is no such field AVSpeechSynthesisProviderVoice { open var name: String { get } open var identifier: String { get } open var primaryLanguages: [String] { get } open var supportedLanguages: [String] { get } open var voiceSize: Int64 open var version: String open var gender: AVSpeechSynthesisVoiceGender open var age: Int } Regards

My team is designing an app for retail associates that need to share managed iPads. We keep the app in Guided Access mode on our login app until an auth token is obtained. Then the iPad is opened for general use. Upon signout we need to re-enter guided access mode and we can do this via manual signout easily. But with idle signout, ie after 60 minutes of inactivity, we need to be able to make a call from the background (in a locked state even) and sign out the user, clear the pin code and enter single app mode before restarting. So that hopefully once the device restarts, we have the app in a locked state again until the next user provides credentials that can obtain a new auth token. We are struggling to see if this is even possible. Our bosses will be displeased if we tell them it isn't. So anybody with any tips would be very appreciated.

SwiftUI provides the accessibilityCustomContent(_:_:) modifier to add additional accessibility information for an element. However, I couldn’t find a similar approach in UIKit. Is there a way to achieve this in UIKit?

After enabling Developer Mode on my iPhone and restarting it, the device asks me to press the Home button to confirm. Unfortunately, my Home button is broken, so I can’t access Developer Mode. The iPhone itself still works, but I can’t enable the mode. Is there any way to bypass this without the Home button?

I am developing a vision os app for controlling an underwater ROV. I have ornaments with telemetry and buttons around a central video view feed. I have custom buttons mappings, such as "A" for locking the depth of the drone. However, when I look at buttons or certain ornaments, my custom gamepad logic is kept from running. This means that when a SwiftUI Button gains focus on visionOS, pressing the controller’s A button triggers the system’s default “click” on that Button rather than my custom buttonA handler. Essentially, focus interception by the system is stealing my A-press events and preventing my custom gamepad logic from running. Is there a way to disable the built in gamepad interaction and only allow my custom gamepad mappings?

I’m trying to set the accessibilityActivationPoint directly on a UITableViewCell so that VoiceOver activate on a specific button inside the cell. However, this approach doesn’t seem to work. Instead, when I override the accessibilityActivationPoint property inside the UITableViewCell subclass and return the desired point, it works as expected. Why doesn’t setting accessibilityActivationPoint directly on the cell work, but overriding it inside the cell does? Is there a recommended approach for handling this scenario? The following approach works, override var accessibilityActivationPoint: CGPoint { get { return convert(toggleSwitch.center, to: nil) } set{ super.accessibilityActivationPoint = newValue } } but setting accessibility point directly not works private func configureAccessibility() { isAccessibilityElement = true accessibilityLabel = titleLabel.text accessibilityTraits = .toggleButton accessibilityActivationPoint = self.convert(toggleSwitch.center, to: self) accessibilityValue = toggleSwitch.accessibilityValue }

I have a parent view containing 10 subviews. To control the VoiceOver navigation order, I set only a few elements in accessibilityElements. However, the remaining elements are not being focused or are completely inaccessible. Is this the expected behavior? If I only specify a subset of elements in accessibilityElements, does it exclude the rest? What’s the best way to ensure all elements remain accessible while customising the order?

I downloaded the official camera sample code（https://developer.apple.com/tutorials/sample-apps/capturingphotos-camerapreview ）it's a .swiftpm package and created a SwiftUI project. I copied the official sample code into this new project, build it, and ran it on an iPhone 13 for testing. I found that there were black empty areas on the top and bottom of the application interface, which means that the application interface cannot be previewed in full screen. I have tried many methods but cannot preview in full screen. How can I modify the code?

AVPlayer has 3 visual accessibility issues with videos out of the box: The contrast fails for the current time in the video The contrast fails for the remaining time in the video The hit area is too small for the time slider. The WCAG AA requirement is a minimum hit size of 24 x 24. The height of the hit area of the offending region is 8. Is there a known fix for any of these? This can be reproduced with this code in an app playground: import SwiftUI import AVKit import UIKit struct ContentView: View { private let video = URL(string: "https://server15700.contentdm.oclc.org/dmwebservices/index.php?q=dmGetStreamingFile/p15700coll2/15.mp4/byte/json")! @State private var player: AVPlayer? var body: some View { VStack { VideoPlayerView(player: player) .frame(maxWidth: .infinity, maxHeight: 200) } .task { player = try? await loadPlayer(video: video) } } } private struct VideoPlayerView: UIViewControllerRepresentable { let player: AVPlayer? func makeUIViewController(context: Context) -> AVPlayerViewController { let controller = AVPlayerViewController() controller.player = player controller.modalPresentationStyle = .overFullScreen return controller } func updateUIViewController(_ uiViewController: AVPlayerViewController, context: Context) { uiViewController.player = player } } private func loadPlayer(video: URL) async throws -> AVPlayer { let videoAsset = AVURLAsset(url: video) let videoPlusSubtitles = AVMutableComposition() try await videoPlusSubtitles.add(videoAsset, withMediaType: .video) try await videoPlusSubtitles.add(videoAsset, withMediaType: .audio) return await AVPlayer(playerItem: AVPlayerItem(asset: videoPlusSubtitles)) } private extension AVMutableComposition { func add(_ asset: AVAsset, withMediaType mediaType: AVMediaType) async throws { let duration = try await asset.load(.duration) try await asset.loadTracks(withMediaType: mediaType).first.map { track in let newTrack = self.addMutableTrack(withMediaType: mediaType, preferredTrackID: kCMPersistentTrackID_Invalid) let range = CMTimeRangeMake(start: .zero, duration: duration) try newTrack?.insertTimeRange(range, of: track, at: .zero) } } }

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

Many of us Bangladeshi iPhone users were upset when Apple changed the font to Bangla in the most recent iOS version (18.4.1). We prefer the old Bangla typeface. I want the old Bangla typeface to return, and so do we. Please consider this.

I'm developing a macOS app using NSView and trying to make my content navigable via VoiceOver. I'm expecting the built-in rotor category "Content Chooser" (accessed via VO + U) to list my accessible elements — just like how it shows message items in the Mail app. However, in my app, this rotor appears empty, even though: My views return proper accessibilityChildren() or accessibilityContents() with valid NSAccessibilityElements Each child has correct AXRole, AXLabel, etc. The window is key and visible VoiceOver navigation works for the elements I've also tried: Using both accessibilityChildren() and accessibilityContents() in container views Setting roles like .group, .staticText, .button, etc. Avoiding hidden elements Ensuring all elements are visible and labeled Still, "Content Chooser" rotor is empty. What exact conditions must be met for an element to appear in the "Content Chooser" rotor in a macOS app? Any Apple-specific guidance, hidden requirements, or sample code would be appreciated.

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