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. :🙏

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?

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?

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