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

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?

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!

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!

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?

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?

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’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

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 have an app that uses nearby with a custom accessory. works great on iPhone 11-13, starting with iPhone 14, one must use ARkit to get angles we have two problems ARkit is light sensitive, and we do not control the lighting where this app would run.. the 11-13 action works great even in the dark. (our users are blind, this is an accessibility app) ARkit wants to be foreground, but our uses cannot see it, and we have a voice oriented UI that provides navigation instructions.. IF ARkit is foreground, our app doesn't work. with iPhone 15 ProMax, on IOS 18, I got an error, access denied. (not permission denied) now that I am on IOS 26.. bt scan doesn't happen also fails same way on iPhone 17 on IOS26, can't callback now as release signing is no longer done this same code works ok on iOS 17.1 on iPhone 12. Info.plist here info.txt if(SearchedServices == [] ){ services = [TransferService.serviceUUID,QorvoNIService.serviceUUID] } logger.info( "scannerready, starting scan for peripherals \(services) and devices \(IDs)") filteredIDs=IDs; scanning=true; centralManager.scanForPeripherals(withServices: services, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) the calling code dataChannel.autoConnect=autoConnect; dataChannel.start(x,ids) // datachannel.start is above self.scanning = true; return "scanning started"; ... log output services from js = and devices= 5FE04CBB services in implementation = bluetooth ready, starting scan for peripherals [] and devices ["5FE04CBB"] scannerready, starting scan for peripherals [6E400001-B5A3-F393-E0A9-E50E24DCCA9E, 2E938FD0-6A61-11ED-A1EB-0242AC120002] and devices ["5FE04CBB"] ⚡️ TO JS {"value":"scanning started"}

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?

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

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

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.

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

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?

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.

I am getting this issue when trying to accept an invite to a new test version of our app. ****Unable to Accept invite This invitation cannot be accepted because your Apple Account, xxxxxxxx.me.com, has already been associated to this app.**** Can you help please?

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?