Since, Apple has long been recognized for its exceptional attention to typography. That is why I am surprised that Smart Punctuation in iOS does not respect national typographic conventions for quotation marks. For example, when writing in Czech, iOS automatically inserts English quotation marks (“…”) instead of the correct Czech form („…“), and there is currently no option to change this behavior. This may seem like a minor detail, but smartphones have become the primary writing tool for millions of people. As a result, the default option of the software does more than automate typing — it shapes writing habits. Or Even more, most users start assuming that automatically inserted punctuation is correct for their language. When iOS consistently uses English quotation marks in Czech text, it unintentionally contributes to the gradual disappearance of Czech typographic conventions. Even professionals often leave the default quotation marks unchanged because correcting them manually in everyday writing is impractical and slows down their writting. Typography is part of every language’s cultural identity. Localization should therefore include not only translated interfaces, but also language-specific typographic standards. Therefore, I would like to suggest that iOS should automatically use quotation marks according to the active keyboard language (or provide a setting to choose the quotation mark style). Czech users would receive „…“, French users « … », German users „…“ or »…« according to regional conventions, and so on. This small change would improve localization, respect linguistic diversity, history, and help preserve national typographic traditions. With the current implementation, Apple unintentionally contributes not only to the widespread use of incorrect writing, but also to the gradual erosion of national typographic traditions and language-specific writing conventions. Daniel

Hello, I would like to suggest adding dedicated keyboard shortcuts or menu commands for opening Notification Center and Control Center in both iOS Simulator and iPhone Mirroring. At the moment, these interfaces generally need to be opened by dragging downward from a specific area at the top of the simulated or mirrored iPhone screen. While this works for normal manual interaction, it is less reliable when using a mouse, especially when the window is resized or when the pointer needs to begin very close to the screen edge. This also creates difficulties for automated UI testing and computer-use agents, such as Codex-based testing workflows. These systems interact with the screen through mouse and keyboard input, so accurately reproducing an edge swipe can be unreliable. A small difference in the starting position may open Spotlight, scroll the current application, move the window, or fail to trigger the system interface entirely. It would be helpful if Apple could provide commands such as: Open Notification Center Open Control Center Dismiss Notification Center or Control Center These commands could be exposed through: Keyboard shortcuts The Simulator “Device” or “Features” menu The iPhone Mirroring toolbar or menu bar Accessibility or UI automation interfaces For example, Simulator already provides menu commands and shortcuts for actions such as pressing the Home button, locking the device, rotating the screen, and triggering other hardware-related interactions. Notification Center and Control Center could be handled in a similar way. This would improve: Manual testing with a mouse and keyboard Automated testing of applications that interact with notifications, media controls, Bluetooth, Focus modes, screen recording, and other system features Accessibility for users who have difficulty performing precise drag gestures Reliability for computer-use and vision-based testing agents Ideally, the commands should behave like genuine system gestures rather than directly changing internal state, so developers can test the complete user-visible interaction. Thank you for considering this feature.

Heya! is there anyway to allow a user to open an accessibility setting from an iOS app? As currently you kinda have to explain how to enable it on your device and honestly thats kinda completely against how accessibility ux should work as it as it requires and expects a user to read+understand something they might as well can't because of accessibility issues in the first place and thus basically punishing a user for it. I tested this with some users and asking them to go trough 3-5 menu's with overwhelming settings is to complex and most give up, thus directing them would solve that problem.

We’re working on improving the accessibility of a MKMapView that displays custom MKAnnotationView instances. Our implementation is fully accessible with VoiceOver: The custom annotation views expose the correct accessibility information. Users can navigate between annotations using custom accessibility rotors. The overall VoiceOver experience works as expected. However, we’re unable to make the custom MKAnnotationView instances accessible through Full Keyboard Access (FKA). Despite configuring the annotation views as accessibility elements and experimenting with focus-related APIs, the annotations never become reachable through keyboard navigation. They appear to be skipped entirely by the FKA focus system. Is there a supported way to make custom MKAnnotationView instances participate in Full Keyboard Access navigation? If this scenario is currently unsupported, is there a recommended approach or any plans to expose public APIs that would allow developers to provide a keyboard-accessible experience for custom annotations in MKMapView? Any guidance would be greatly appreciated.

I'm building an iOS app in SwiftUI and need to adapt my UI when Voice Control is active — specifically to show labels on custom gesture-driven controls so they're accessible via Voice Control commands. I've checked UIAccessibility and can find notifications and properties for VoiceOver (isVoiceOverRunning), Switch Control (isSwitchControlRunning), and AssistiveTouch (isAssistiveTouchRunning), but I can't find any equivalent for Voice Control. UIAccessibility.isVoiceControlRunning and voiceControlStatusDidChangeNotification appear to exist on macOS (AXIsProcessTrustedWithOptions) but not on iOS. Questions: Is there a public iOS API to detect whether Voice Control is currently active — either a UIAccessibility property, notification, or SwiftUI environment value? If not, is the recommended approach to use UIAccessibility.isGuidedAccessEnabled as a proxy, or something else entirely? Is there a private entitlement or capability that unlocks this detection for App Store apps? What I've already tried: Checking AccessibilityFeatures environment values in SwiftUI (@Environment(.accessibilityReduceMotion) etc.) Thanks!

Experiencing an issue with UIContextualAction title text respecting the user's Dynamic Type / preferred content size category when Liquid Glass is active. It's setup using a UITableView with trailing swipe actions via trailingSwipeActionsConfigurationForRowAt. Under Liquid Glass, the contextual action buttons render as floating glass pills, but the title text within them remains at a fixed size regardless of the Dynamic Type setting. Increasing the preferred content size category to accessibility sizes has no visible effect on the action label font size. Any suggestions to make this scalable for dynamic font

Hi, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

I find the inspector, file navigator, issue navigator, etc. all hard to read. Is there a way to increase the size of these texts without changing all of the text on my machine?

Hi, I want to detect if there is a fullscreen window on each screen. _AXUIElementGetWindow and kAXFullscreenAttribute methods work, but I have to be in a non-sandbox environment to use them. Is there any other way that also works? I don't think it's enough to judge if it's fullscreen by comparing the window size to the screen size, since it doesn't work on MacBook with notch, or the menu bar is set to 'auto-hide'. Thanks.

User might be caught in a Guided Access page with error like this when they trying to leave Guided Access. Please pardon me for shotting a photo with phone to show this condition, because I can't even get a screenshot with home button and power key pressed together. I can't lock the screen with power key or by the magnet sensor, can't get back home page with home button. The ways to exit is waiting for the exit button might could use, or the screen shutdown, or enforce the device to shutdown. After exit the Guided Access without rebooting the system, the Guided Access would be freezed for minutes, noticing the Guided Access can't be used. In iPadOS 26, since, I can prove confidently, 26.5beta1 even earlier, could discover that issue. The problem could happen several times in a day. I have raised that issue since April 25th and the ID is FB22608734, which has more than 10 similar reports. To say something beyond the issue, actually I guessed that my device, iPad mini 5th, might can't get the update of iPadOS 27, so I hoped that Apple Developer Teams could at least fix those annoying problems. Actually there is a long list in Chinese with problems summarised by some Chinese User I waited for a long time for a miracle in WWDC 27. But that's a miracle.

Environment: Xcode 26.5, macOS Tahoe 26.5.1 (MacBook Pro, Apple M4 Max). As a blind developer working in Xcode with VoiceOver only, I'd like to report accessibility issues that make it hard to complete properly signed and entitled apps using VoiceOver alone. Issue: The "Signing & Capabilities" tab is not directly accessible. The "Signing & Capabilities" tab in the target editor is central to app configuration (team selection, capabilities, provisioning profiles), but there is no dedicated keyboard shortcut to reach it. The path requires many steps: Cmd+1 to focus the navigator, selecting the project file with the arrow keys, activating it with Return, switching to the central editor area, selecting the target, and finally locating the tab in the top bar. Specific VoiceOver problems: When the project file is activated with VoiceOver, focus often lands inside the inline rename field instead of opening the project editor as expected. The toolbar containing the editor tabs (General, Signing & Capabilities, Resource Tags, Info, Build Settings, Build Phases, Build Rules) cannot reliably be focused with VoiceOver, which prevents direct tab switching from the keyboard. Impact: A routine task such as adding a capability requires a long VoiceOver sequence that must be repeated on every visit, plus the cognitive load of remembering the exact tab order. Suggested improvements: Provide a direct keyboard shortcut for the "Signing & Capabilities" tab, and ideally for each target editor tab (for example Cmd+Option+1 through Cmd+Option+7). Ensure that activating the project file in the navigator opens the project editor by default; renaming should require an explicit second key press (Return on an already selected item, consistent with Finder). Ensure the editor tab bar can be reached and traversed with VoiceOver, for example via Tab or Ctrl+Tab.

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 using Dynamic Font throughout my entire app yet the audits in Accessibility Inspector will give me a ton of "Dynamic Type font sizes are unsupported: User will not be able to change the font size of this SwiftUI.AccessibilityNode" warnings. This is incorrect because users are able to change the font size. I can even move to the inspector panel and adjust the font and see it all change right within the Accessibility Inspector. I assume this is a bug since I can change the font but I was also wondering if there's some special thing I'm missing that could prevent these warnings from appearing especially when management runs audits to look for deficiencies.

I would like to implement a focus-based Menu-Bar command in my SwiftUI iPadOS app, or react to key command while certain elements are focused. Traditionally, this requires using @FocusedValue and focusable() and focused, however, it appears that setting a @FocusState on macOS will work, but setting a @FocusState on iPadOS will never work. How can this API work and support MenuBar commands and keyboard inputs? It kind of has an accessibility impact as well. Not all users are going to know, or want to turn on "full keyboard control" for basic interactions. Here's a small sample that doesn't appear to focus on iPadOS: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField("Enter text", text: .constant("")) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom "input" should focus itself when tapped: Rectangle() .fill(isRectFocused ? Color.accentColor : Color.gray.opacity(0.3)) .frame(width: 100, height: 100) .overlay( Text(isRectFocused ? "Focused" : "Tap me") ) .focusable(true) .focused($isRectFocused) .onTapGesture { isRectFocused = true print("Focused rectangle") } // The focus should be able to be controlled externally: Button("Toggle Focus") { isRectFocused.toggle() } .buttonStyle(.bordered) } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) } }

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID). Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

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 (26.0–26.5), a rectangular region in the lower half of the screen sometimes does not render while the content underneath remains laid out and interactive — scrolling works, hit testing succeeds, and rows visibly emerge from behind the floating tab bar as you scroll. This is a render-server / compositor gap, not a layout or safe-area issue. We see it on both UIKit and SwiftUI scroll surfaces inside the same UITabBarController: UIKit: UICollectionView with UICollectionViewFlowLayout (sectionInsetReference = .fromSafeArea) SwiftUI: List(.plain) nested in TabView(.page) inside a UIHostingController Confirmed on iPhone 16 Pro, iPhone 17 Pro, iPhone 13 Pro Max. Community threads (linked below) report the same symptom in Messages, Notes, Safari, Mail, and the App Store. Questions for Apple Is this acknowledged as an OS-level regression, and is a fix targeted for an upcoming iOS 26.x release? Is there a deterministic repro? We've tried background/foreground cycles, push notifications mid-scroll, tab switches during inertia, lock/unlock, orientation flips, simulated memory warnings, layout-invalidation storms, and trait-collection cycles — none reliably trigger it on our test devices. Is there a developer-side mitigation (e.g. avoiding specific UIVisualEffectView / Glass configurations, opting out of a rendering optimization) until a system fix lands? Is there a runtime signal on CALayer or UIScrollView we can inspect to detect this gap state and force a recovery (tile redraw, backing-store discard, etc.)? Notes We cannot reproduce locally. Affected users hit it organically; once it appears it persists across re-layout until the view controller is torn down. Community reports consistently mention Reduce Transparency being enabled on affected devices, and toggling it off clears the issue for many. In our own testing, RT alone is not sufficient to trigger the bug — it appears to be a contributing condition rather than the trigger. References: Apple Discussions: https://discussions.apple.com/thread/256182149 Reddit r/ios (multiple system apps): https://www.reddit.com/r/ios/comments/1nlzn7f/some_apps_cutting_off_half_the_display/ https://www.idownloadblog.com/2026/03/23/webpage-content-cutting-off-safari/

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

I am developing an iOS app using ActivityKit Live Activities with interactive buttons based on LiveActivityIntent. The implementation works correctly: LiveActivityIntent.perform() executes correctly. The Live Activity updates visually. MediaPlayer actions are triggered successfully. The app does not open when tapping the buttons. Repeated taps correctly update the Live Activity state. However, I observed a behavior difference on the Lock Screen: Now Playing controls keep the Lock Screen awake while interacting repeatedly. Apple Stopwatch/Timer controls also keep the Lock Screen awake while interacting. My app’s Live Activity fades to black after around 5–7 seconds even while the user continues tapping the Live Activity buttons. I also tested a third-party timer app with Live Activity buttons and observed the same fade-to-black behavior. I additionally tested: repeated Activity.update(...) calls after each tap; visual state updates after every interaction; multiple consecutive interaction updates. None of these prevented the Lock Screen from dimming/fading to black. So my question is: Is this expected behavior for third-party Live Activities using LiveActivityIntent? Or is there any recommended way to keep the Lock Screen interaction session active while the user is continuously interacting with Live Activity buttons? I am especially interested from an accessibility perspective, because short interaction windows can make repeated Lock Screen interactions more difficult for users with motor impairments or slower interaction patterns.