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.

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

OK hello Apple developers, and whoever else is reading, I am a quadriplegic. This means I cannot use my fingers. So therefore I cannot pick up the phone. That means I cannot pick up the phone for Face ID which is biometric, fingerprint which is biometric, I believe the eye is biometric. So is the voice. That is how I have to login to my brokerage firms multiple bank account. Anything super secure I can use my voice as a password. It's super simple. Just add and the code and write it so therefore it is as simple as saying something to the effect of "hey seri my voice is my password. A few simple lines of code written by Apple expert this should not be hard at all and should be included in an update. Just think how would you use your phone if you could not pick it up. I cannot put Apple Pay i cannot secure on my phone because I cannot lock it because I cannot pick it up. Any help would be greatly appreciated

I am a quadriplegic. That means when I ask Siri something she comes back with an answer saying this is what I found on the web. This means nothing to me because I cannot use my fingers to pick up the phone. I I get a better and more detail from Alexa or Google nest. Go ahead and Google and or and Apple AI actually intelligent

I’m implementing an Apple AssistiveTouch eye tracker accessory for iPad over USB-C using iAP2 plus native HID Gaze Point reports. Current state: iAP2 authentication succeeds identification succeeds StartNativeHID is received AssistiveTouchInformation(IsEnabled=true) is received iPadOS enumerates the HID interface and consumes the interrupt IN reports The remaining issue is that the gaze-point behavior is not interpreted as direct screen coordinates. Repeated fixed gaze inputs produce deterministic but incorrect cursor motion, often appearing like orbiting or projection around a locus rather than stable placement. I have tested: the 119-byte Apple example HID descriptor from the Accessory Interface Specification two report-1 layouts: timestamp + x + y status + timestamp + x + y normalized and physical coordinate scaling verified on the wire that the intended report bytes are sent and consumed iPad console logs show internal model point (HID r) values and multiple derived Pointer positions for a single commanded point, which suggests the device is accepted but the gaze report semantics are still not what iPadOS expects. Questions: Is the example Gaze Point HID descriptor in the Apple Accessory Interface Specification sufficient as-is for iPadOS? What exact payload layout is expected for the Gaze Point report? Is a per-sample status byte required in the gaze input report? Are additional HID feature/input reports required for correct interpretation? I can provide: the exact HID descriptor bytes sample report payloads USB analyzer traces iPad console excerpts showing the resulting model-point and pointer projections

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?

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?

On tvOS, third-party apps cannot read number key presses from a connected keyboard or remote (except inside a text field). There is also no HDMI-CEC API. Because of this, a live-TV / IPTV app cannot let the user simply type a channel number to change channels. This excludes a large group of users, especially older people. They have used numbered channels for their whole lives — they remember that a given number is a specific channel and just want to press that number to get there. It is the simplest and most familiar way for them to use a TV. Making them navigate an on-screen grid with the Siri Remote instead is much harder and unfamiliar for them. Please give apps a way to support numeric channel entry on tvOS — for example by letting apps receive number key presses (0–9) from a connected Bluetooth keyboard/keypad without forcing a text field, or by exposing the numeric keys from the TV's own remote via HDMI-CEC. Other TV platforms already pass number keys from the remote to apps, so this works for them today. tvOS does not, which leaves these users without a basic, expected way to use their TV.

I have enabled "Voice Over" in the Device -> Accessibility Menu of the Device Hub, but I hear no Output. I was expecting Voice Over to be active when this option is selected. Running Xc 27 on MacOS 26.5. Do I need to be on MacOS 27?

I reported it to the beta team already but I was wondering if anybody else is not able to get there device to restart just by one tap using the AssistiveTouch menu?

Hello, In this press release from last month: https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ It indicates the following: "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." I have looked over the WWDC26 sessions but have not been able to find any information on this new API. Can you point me in the right direction? Thank you!

Can developers programmatically turn on Reduce (Liquid Glass) Transparency for their app? Or just for a view? Or will iOS 27 permit setting Reduce Transparency on an app-by-app basis?

"On an iPhone 16 Pro running iOS 27 Developer Beta 1, the system search index has remained stuck on 'Indexing in progress' for 29 hours following Siri app access approval at 3 PM yesterday. The local file system is unburdened—there are no complex media or custom font directories present, and third-party app assets are strictly isolated within standard sandboxed containers. This indicates that the Beta 1 indexing persistence is an architectural logic stall or an authentication validation loop triggered by the waitlist activation token, rather than a storage-volume bottleneck."

for example: Our designers want our "Disclosures/Legal" info icon, to be 4px from the text. So we end up needing to "hack" around the view, to make the info tap target exist "over" the text. without any hacks, if we use a 20x20 icon + 4 padding, the tap target is only 28px wide. the "hack" in question, usually involves adding paddings + inverted (negative) padding, to increase the tap target, without affecting layout

The existing API is roughly imported into Swift and pretty thorny. Some of this can be addressed with a wrapper library but some of it is much more difficult, like addressing AXObserver not having a finished event or callback to signify when it would be safe to do cleanup in a concurrent environment. A Swift overlay could be a great opportunity to make third part assistive tech more accessible.

I have enabled "Voice Over" in the Device -> Accessibility Menu of the Device Hub, but I hear no Output. I was expecting Voice Over to be active when this option is selected. Running Xc 27 on MacOS 26.5. Do I maybe need to be on MacOS 27?

For example, we have a "card view" that navigates to a comprehensive detail screen... But there's an ellipsis on the card as well, that shows a menu of quick actions. We need both to be tappable. (SwiftUI project)

When I try to inspect elements in the device hub, only the full window (group) is selectable. Am I doing it wrong? (FB22976268)

Given the new Voice Control natural language enhancements, is there any change in guidance for how developers use accessibilitylnputLabels? Does providing robust utterance coverage across our views still help tune the new system's NLU?

I have been trying for 7 months to speak to someone at Apple about their accessibility work for my job as assistive technology advisor. I haven’t been able to speak to anyone regarding this despite emailing a number of different departments and people at Apple. Other tech firms have been happy to become involved, can anyone help?