Post

Replies

Boosts

Views

Activity

A Plea to Apple: Please Listen to Visually Impaired Users
This post is a translated and condensed version of the original article: https://developer.apple.com/forums/thread/843626. ChatGPT was used to help refine the English wording and shorten the content to meet the 7,000-word limit. The original meaning and key suggestions have been retained as much as possible. A Letter to Apple’s Accessibility Engineering Team 1. Purpose I am a visually impaired user from Hong Kong and have used iPhone VoiceOver and Zoom for many years. I have encountered issues with zoom gestures, focus handling, and pop-up navigation. Please log these proposals and diagnostic files as a formal feature request and forward them to Apple’s Asia-Pacific accessibility engineering team. 2. User Feedback Challenges Many visually impaired users face similar barriers, but official feedback often receives no follow-up. Front-line staff may lack the expertise to communicate these issues accurately, so reports can be treated as general usability problems rather than accessibility concerns. Small system changes could help many people, while active reporters represent only a fraction of those affected. 3. Screen Zoom Gestures When VoiceOver is enabled, activating Zoom with a three-finger double-tap can be difficult for people with hand tremors or limited dexterity. Coordinating three fingers makes it hard to target an area accurately, pan smoothly, and maintain consistent screen contact. The Zoom Controller can obscure content and may be accidentally activated alongside nearby controls. Apple could explore simpler gestures like Android’s magnification, which uses one finger to activate and two fingers to adjust or pan, while retaining the zoom level after the fingers leave the screen. 4. VoiceOver Gestures and Focus 4.1 Customisable Gestures Common actions can require navigating several Rotor options. Add customisable gesture combinations, such as swiping up then down or left then right, to trigger shortcuts. Customisable virtual bars along both screen edges could also provide audio or haptic feedback when touched and held, then trigger shortcuts when users swipe up or down by different distances. 4.2 Automatic Focus Grouping In third-party apps, labels and their switches are often separate VoiceOver focus elements. Automatically grouping related labels and switches would let VoiceOver announce the information and allow users to operate the switch without an extra swipe. 5. Contrast and Selection Visibility System switches can be difficult for users with low vision to distinguish. Consider a highly saturated dark-blue track when enabled, with a contrasting thumb colour, to make its state clearer than the grey disabled track. Make Settings checkmarks bolder or give selected items a dark background. In multi-select lists, consider a separate tab for selected items or automatically moving selected items to the top. This would make selection states easier to identify visually and with VoiceOver. 6. Native iOS Keyboard Keyboard size and editing: Allow keyboard-height adjustment and an optional full-screen text-editing mode for reviewing text in small third-party fields. High contrast: Offer a black keyboard with white text and keep its appearance consistent across apps when Dark Mode or Smart Invert is enabled. Dictation: Let users start dictation by holding the space bar and stop when they release it. Chinese speech-to-text: Improve language models and use sentence context to distinguish homophones and correct errors, especially for long dictation by VoiceOver users. 7. Assistive Access Assistive Access can disable VoiceOver gestures, including swiping up from the bottom to return Home. Improve compatibility between the two features. Consider adding power-saving options such as reducing screen resolution and CPU frequency, using a pure-black theme, and disabling image loading. These options could help users with older devices, visual impairments, or other accessibility needs. 8. Real-Time AI Screen Recognition Third-party apps may have buttons that cannot receive accessibility focus, missing labels, or controls that existing screen recognition cannot identify. Apple could develop system-level AI to analyse screens in real time, identify interface elements, generate labels, and make interactive controls actionable. If reliable enough, this could address more barriers at system level. Apple could also explore a shared accessibility-label database where users submit corrections that synchronise across apps and devices. 9. Navigation and Pop-up Dismissal With VoiceOver, returning to a previous page often means swiping through elements to find a small Back button. Expand its accessibility hit area so it is easier to locate and activate. Close and Cancel buttons appear in inconsistent locations, and pop-ups, nested menus, or keyboards can be difficult to dismiss. Where appropriate, tapping outside a pop-up should dismiss it by default, reducing the risk of users becoming trapped. 10. Traditional Chinese Settings and Navigation Some Traditional Chinese accessibility settings have vague names or descriptions. Clarify options such as VoiceOver “Hints” and reduce redundant announcements that may continue even after Hints are turned off. Group related settings—such as Raise to Wake, Tap to Wake, and automatic brightness—on the same page. Place icons beside titles and descriptions rather than stacking them vertically, so more options fit on screen and VoiceOver users need to scroll less. 11. Ultra Low Power Mode Add an Ultra Low Power Mode alongside Low Power Mode, with optional controls to: Pause animations and GIFs. Disable non-essential system animations and visual effects. Disable autoplay for message effects, video previews, and animated content. Disable selected display adjustments where supported. Turn off Liquid Glass effects where possible. Turn off Raise to Wake by default. Disable app suggestions, learning, and shortcuts in Search, widgets, and notifications. Place these controls in one panel, with a low-power default and the option to re-enable features individually. Reducing unnecessary animation and background processing could improve battery life, responsiveness, and device temperature, depending on the device and implementation. A simpler interface could also reduce visual distractions for VoiceOver users. 12. Summary These proposals address barriers to the everyday independence of people who are blind or have low vision. Even small changes could help users operate their devices more easily. I hope Apple will take these suggestions and users’ real-world experiences seriously. Submitted by: A visually impaired user from Hong Kong, China
0
2
932
2w
Best practices for iOS Full Keyboard Access navigation?
Hi 👋, I’m working on improving Full Keyboard Access support in an iOS app and would love to hear about your experience. When developing for keyboard navigation, what approach do you usually take for navigating between UI elements? Do you mainly use Tab/Ctrl+Tab, arrow keys, or a combination of both? I’ve already watched some WWDC sessions and Apple's docs on this topic: https://developer.apple.com/design/human-interface-guidelines/keyboards https://developer.apple.com/videos/play/wwdc2021/10120/ https://developer.apple.com/videos/play/wwdc2021/10260/ https://developer.apple.com/documentation/UIKit/navigating-an-app-s-user-interface-using-a-keyboard However, I’d appreciate any recommendations for useful resources, documentation, or things to be aware of when implementing keyboard accessibility. :🙏
1
1
1.6k
Sep ’26
iOS 27 Beta: UISearchTab's search field ignores the horizontal safe area in landscape (correct on iOS 26)
On iOS 27 beta, when a search field hosted by a UISearchTab becomes active in landscape on a device with a sensor housing, the field lays out edge-to-edge, and its leading magnifier ends up inside the safe area inset. The same code is correct on iOS 26, so this looks like a regression. It then gives the environment, the setup (tabs API + UISearchTab with automaticallyActivatesSearch, plain UISearchController assigned in init, no placement or scrolling flags, no custom bar subclass), expected versus actual, and the measurements: window = 812 x 375, safeAreaInsets left/right 50 (usable 50…762) tab-hosted, active: field = (8.0, 122.0, 744.0, 44.0) ← 42pt inside the left inset tab-hosted, idle: field = (94.0, 311.0, 680.0, 44.0) ← trailing edge overruns by 12pt presented (no tabs): field = (101.7, 126.7, 553.0, 30.7) ← fully inside iOS 26 iOS 27 Not sure if it's known/has a supported workaround.
0
0
610
Aug ’26
How can users scroll a UIScrollView with Full Keyboard Access to reach off-screen content?
Our app supports Full Keyboard Access. We have a scroll view containing content that extends beyond the visible area. When navigating with the keyboard, focusable elements inside the scroll view are reached and the view scrolls to follow focus, but content that has no focusable elements (e.g. long blocks of static text, images, or footer content below the last control) can't be brought into view by the keyboard alone. Is there a supported way for Full Keyboard Access users to scroll a scroll view to see this off-screen, non-focusable content — e.g. a built-in scroll command, or an API to make the scroll view itself focusable/scrollable via the keyboard — without resorting to custom key handling?
0
0
1k
May ’26
Can the Full Keyboard Access focus indicator be removed entirely?
Our app supports Full Keyboard Access. When an element is focused, the system-drawn FKA focus indicator (the ring/overlay) sits over the UI component. This overlay drops the content's colour contrast below the WCAG 2.1 minimums — 4.5:1 for text (1.4.3) and 3:1 for UI components and focus indicators (1.4.11) — causing the focused state to fail accessibility audits. Is there a supported way to completely remove this focus overlay on a view without breaking FKA keyboard navigation or VoiceOver?
1
0
928
May ’26
iOS 26 Full Keyboard Access with custom UITableViewCell
On iOS 26 with Full Keyboard Access enabled, a UITableView(style: .grouped) with custom cells only enumerates section 0 in the Ctrl+Tab focus order (But it works with arrow keys). Cells in sections 1+ are reachable via arrow keys, and canFocusRowAt fires and returns true when arrows spatially reach them — but Tab leaves the table after the last row of section 0 and jumps to the next focus item outside the table. Same code works correctly on iOS 18.x. focusGroupIdentifier strategies (single ID on the table, same ID across view/table/every cell, unique ID per cell) have no effect. tableView.allowsFocus is true. Is this a known iOS 26? Has anyone else run into this? final class CardCell: UITableViewCell { private let cardView = UIView() override init(style: CellStyle, reuseIdentifier: String?) { super.init(style: style, reuseIdentifier: reuseIdentifier) cardView.backgroundColor = .white cardView.translatesAutoresizingMaskIntoConstraints = false contentView.addSubview(cardView) NSLayoutConstraint.activate([ cardView.topAnchor.constraint(equalTo: contentView.topAnchor), cardView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), cardView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), cardView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), ]) } required init?(coder: NSCoder) { fatalError() } } // Table: UITableView(style: .grouped), 3 sections, register CardCell. // Reproduce on iOS 26 with FKA on → Tab from section 0 leaves the table, // skipping every cell in sections 1+.
1
0
1.4k
May ’26
A Plea to Apple: Please Listen to Visually Impaired Users
This post is a translated and condensed version of the original article: https://developer.apple.com/forums/thread/843626. ChatGPT was used to help refine the English wording and shorten the content to meet the 7,000-word limit. The original meaning and key suggestions have been retained as much as possible. A Letter to Apple’s Accessibility Engineering Team 1. Purpose I am a visually impaired user from Hong Kong and have used iPhone VoiceOver and Zoom for many years. I have encountered issues with zoom gestures, focus handling, and pop-up navigation. Please log these proposals and diagnostic files as a formal feature request and forward them to Apple’s Asia-Pacific accessibility engineering team. 2. User Feedback Challenges Many visually impaired users face similar barriers, but official feedback often receives no follow-up. Front-line staff may lack the expertise to communicate these issues accurately, so reports can be treated as general usability problems rather than accessibility concerns. Small system changes could help many people, while active reporters represent only a fraction of those affected. 3. Screen Zoom Gestures When VoiceOver is enabled, activating Zoom with a three-finger double-tap can be difficult for people with hand tremors or limited dexterity. Coordinating three fingers makes it hard to target an area accurately, pan smoothly, and maintain consistent screen contact. The Zoom Controller can obscure content and may be accidentally activated alongside nearby controls. Apple could explore simpler gestures like Android’s magnification, which uses one finger to activate and two fingers to adjust or pan, while retaining the zoom level after the fingers leave the screen. 4. VoiceOver Gestures and Focus 4.1 Customisable Gestures Common actions can require navigating several Rotor options. Add customisable gesture combinations, such as swiping up then down or left then right, to trigger shortcuts. Customisable virtual bars along both screen edges could also provide audio or haptic feedback when touched and held, then trigger shortcuts when users swipe up or down by different distances. 4.2 Automatic Focus Grouping In third-party apps, labels and their switches are often separate VoiceOver focus elements. Automatically grouping related labels and switches would let VoiceOver announce the information and allow users to operate the switch without an extra swipe. 5. Contrast and Selection Visibility System switches can be difficult for users with low vision to distinguish. Consider a highly saturated dark-blue track when enabled, with a contrasting thumb colour, to make its state clearer than the grey disabled track. Make Settings checkmarks bolder or give selected items a dark background. In multi-select lists, consider a separate tab for selected items or automatically moving selected items to the top. This would make selection states easier to identify visually and with VoiceOver. 6. Native iOS Keyboard Keyboard size and editing: Allow keyboard-height adjustment and an optional full-screen text-editing mode for reviewing text in small third-party fields. High contrast: Offer a black keyboard with white text and keep its appearance consistent across apps when Dark Mode or Smart Invert is enabled. Dictation: Let users start dictation by holding the space bar and stop when they release it. Chinese speech-to-text: Improve language models and use sentence context to distinguish homophones and correct errors, especially for long dictation by VoiceOver users. 7. Assistive Access Assistive Access can disable VoiceOver gestures, including swiping up from the bottom to return Home. Improve compatibility between the two features. Consider adding power-saving options such as reducing screen resolution and CPU frequency, using a pure-black theme, and disabling image loading. These options could help users with older devices, visual impairments, or other accessibility needs. 8. Real-Time AI Screen Recognition Third-party apps may have buttons that cannot receive accessibility focus, missing labels, or controls that existing screen recognition cannot identify. Apple could develop system-level AI to analyse screens in real time, identify interface elements, generate labels, and make interactive controls actionable. If reliable enough, this could address more barriers at system level. Apple could also explore a shared accessibility-label database where users submit corrections that synchronise across apps and devices. 9. Navigation and Pop-up Dismissal With VoiceOver, returning to a previous page often means swiping through elements to find a small Back button. Expand its accessibility hit area so it is easier to locate and activate. Close and Cancel buttons appear in inconsistent locations, and pop-ups, nested menus, or keyboards can be difficult to dismiss. Where appropriate, tapping outside a pop-up should dismiss it by default, reducing the risk of users becoming trapped. 10. Traditional Chinese Settings and Navigation Some Traditional Chinese accessibility settings have vague names or descriptions. Clarify options such as VoiceOver “Hints” and reduce redundant announcements that may continue even after Hints are turned off. Group related settings—such as Raise to Wake, Tap to Wake, and automatic brightness—on the same page. Place icons beside titles and descriptions rather than stacking them vertically, so more options fit on screen and VoiceOver users need to scroll less. 11. Ultra Low Power Mode Add an Ultra Low Power Mode alongside Low Power Mode, with optional controls to: Pause animations and GIFs. Disable non-essential system animations and visual effects. Disable autoplay for message effects, video previews, and animated content. Disable selected display adjustments where supported. Turn off Liquid Glass effects where possible. Turn off Raise to Wake by default. Disable app suggestions, learning, and shortcuts in Search, widgets, and notifications. Place these controls in one panel, with a low-power default and the option to re-enable features individually. Reducing unnecessary animation and background processing could improve battery life, responsiveness, and device temperature, depending on the device and implementation. A simpler interface could also reduce visual distractions for VoiceOver users. 12. Summary These proposals address barriers to the everyday independence of people who are blind or have low vision. Even small changes could help users operate their devices more easily. I hope Apple will take these suggestions and users’ real-world experiences seriously. Submitted by: A visually impaired user from Hong Kong, China
Replies
0
Boosts
2
Views
932
Activity
2w
Best practices for iOS Full Keyboard Access navigation?
Hi 👋, I’m working on improving Full Keyboard Access support in an iOS app and would love to hear about your experience. When developing for keyboard navigation, what approach do you usually take for navigating between UI elements? Do you mainly use Tab/Ctrl+Tab, arrow keys, or a combination of both? I’ve already watched some WWDC sessions and Apple's docs on this topic: https://developer.apple.com/design/human-interface-guidelines/keyboards https://developer.apple.com/videos/play/wwdc2021/10120/ https://developer.apple.com/videos/play/wwdc2021/10260/ https://developer.apple.com/documentation/UIKit/navigating-an-app-s-user-interface-using-a-keyboard However, I’d appreciate any recommendations for useful resources, documentation, or things to be aware of when implementing keyboard accessibility. :🙏
Replies
1
Boosts
1
Views
1.6k
Activity
Sep ’26
iOS 27 Beta: UISearchTab's search field ignores the horizontal safe area in landscape (correct on iOS 26)
On iOS 27 beta, when a search field hosted by a UISearchTab becomes active in landscape on a device with a sensor housing, the field lays out edge-to-edge, and its leading magnifier ends up inside the safe area inset. The same code is correct on iOS 26, so this looks like a regression. It then gives the environment, the setup (tabs API + UISearchTab with automaticallyActivatesSearch, plain UISearchController assigned in init, no placement or scrolling flags, no custom bar subclass), expected versus actual, and the measurements: window = 812 x 375, safeAreaInsets left/right 50 (usable 50…762) tab-hosted, active: field = (8.0, 122.0, 744.0, 44.0) ← 42pt inside the left inset tab-hosted, idle: field = (94.0, 311.0, 680.0, 44.0) ← trailing edge overruns by 12pt presented (no tabs): field = (101.7, 126.7, 553.0, 30.7) ← fully inside iOS 26 iOS 27 Not sure if it's known/has a supported workaround.
Replies
0
Boosts
0
Views
610
Activity
Aug ’26
How can users scroll a UIScrollView with Full Keyboard Access to reach off-screen content?
Our app supports Full Keyboard Access. We have a scroll view containing content that extends beyond the visible area. When navigating with the keyboard, focusable elements inside the scroll view are reached and the view scrolls to follow focus, but content that has no focusable elements (e.g. long blocks of static text, images, or footer content below the last control) can't be brought into view by the keyboard alone. Is there a supported way for Full Keyboard Access users to scroll a scroll view to see this off-screen, non-focusable content — e.g. a built-in scroll command, or an API to make the scroll view itself focusable/scrollable via the keyboard — without resorting to custom key handling?
Replies
0
Boosts
0
Views
1k
Activity
May ’26
Can the Full Keyboard Access focus indicator be removed entirely?
Our app supports Full Keyboard Access. When an element is focused, the system-drawn FKA focus indicator (the ring/overlay) sits over the UI component. This overlay drops the content's colour contrast below the WCAG 2.1 minimums — 4.5:1 for text (1.4.3) and 3:1 for UI components and focus indicators (1.4.11) — causing the focused state to fail accessibility audits. Is there a supported way to completely remove this focus overlay on a view without breaking FKA keyboard navigation or VoiceOver?
Replies
1
Boosts
0
Views
928
Activity
May ’26
iOS 26 Full Keyboard Access with custom UITableViewCell
On iOS 26 with Full Keyboard Access enabled, a UITableView(style: .grouped) with custom cells only enumerates section 0 in the Ctrl+Tab focus order (But it works with arrow keys). Cells in sections 1+ are reachable via arrow keys, and canFocusRowAt fires and returns true when arrows spatially reach them — but Tab leaves the table after the last row of section 0 and jumps to the next focus item outside the table. Same code works correctly on iOS 18.x. focusGroupIdentifier strategies (single ID on the table, same ID across view/table/every cell, unique ID per cell) have no effect. tableView.allowsFocus is true. Is this a known iOS 26? Has anyone else run into this? final class CardCell: UITableViewCell { private let cardView = UIView() override init(style: CellStyle, reuseIdentifier: String?) { super.init(style: style, reuseIdentifier: reuseIdentifier) cardView.backgroundColor = .white cardView.translatesAutoresizingMaskIntoConstraints = false contentView.addSubview(cardView) NSLayoutConstraint.activate([ cardView.topAnchor.constraint(equalTo: contentView.topAnchor), cardView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), cardView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), cardView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), ]) } required init?(coder: NSCoder) { fatalError() } } // Table: UITableView(style: .grouped), 3 sections, register CardCell. // Reproduce on iOS 26 with FKA on → Tab from section 0 leaves the table, // skipping every cell in sections 1+.
Replies
1
Boosts
0
Views
1.4k
Activity
May ’26