I am a huge techie person. I love programming, Macs and PC. my all of my codebase and projects use open source software. I am also been a fan of the environment. With the changes in climate in the past and lately I have been moderately conservative on my tech purchases. Because of this I have a pulsing question on what is Apple's end game for EOL Apple silicon? I mean if you look at the power packed Apple Silicon Macs and its enclosure it looks environmentally friendly, recyclable and sustainable. The enclosure is recyclable. the hardware interface looks minimal to the sense that the waste is just the PCB that the interface is laid out on. Think of the current iPhone it looks really recyclable and sustainable. But because I changed drastically and the price of tech right now is not buyable or viable to me I would like to ask what is Apple's end game on EOL Apple Silicon Macs. Price and sustainability? I am an avid watcher of current recycling break throughs and believe me it gave me solutions not just recycling but it also gave me a mission. The primary solution I want to solve and ask you guys if is there effort to put OpenBSD on apple silicon? I like Linux on my x86 machine but for Apple Silicon since it is unix based I want to work on BSD based projects. Any input from Apple developers out there would be nice. I just to find a way to repurpose Apple Silicon Macs because its has a great hardware and from the looks of it I would like to keep it and run it with an OS close to macOS. Please put your input. I/O peace out.

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

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.

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.

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

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?

I found difficulty interacting with close button on placement inside Health app on newest iOS. Steps to reproduce: Open Health app Scroll to "Get more from health" Try to focus on close button on any box like "Set Up your medical ID" Focus is on the whole box and there is now way to move to close button. After hitting space it opens next screen. Solving this issue might help with similar issue in our app.

When using Full Keyboard Access some content in Reminders app is not accessible. Steps to reproduce: Open Reminders app Open one of the lists with few (ex. 4) records. Try to check reminder. Issue: Navigating with keyboard focuses on whole row, using arrows left/right doesn't move to check control. Using space on whole row activates textfield, then still left/right arrow does not move outside textfield. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard. Solving this issue might help with similar issues in our app.

When using Full Keyboard Access on iPhone in Photos app some interactive content is not available to enter. Steps to reproduce: Open Photos app Go to Collections tab Go to memories Try to select any memory playlist Whole scroll view is selectable as one element and using space is not making any difference. Using tab goes to navigation controls. Tested on iPhone 13 mini with iOS 26.4 using Magic Keyboard.

When Full Keyboard Access is enabled, some controls in the Photos app appear to be unreachable using keyboard navigation. Steps to reproduce: Enable Full Keyboard Access. Open the Photos app. Navigate to the Collections tab. Use arrow keys to move focus through the screen. The Info (“i”) button related to library optimization is not reachable. When focus is on the left side (e.g. “Reorder”), pressing the down arrow moves focus directly to the tab bar. When focus is on the right side (e.g. the chevron next to “Wallpaper Suggestions”), focus moves directly to the Search button. The Info button is skipped in both cases. Tested on simulator iPhone 17 Pro with iOS 26.2.

Hello, i'm currently working on improving accessibility in my app using the built-in Xcode tool, Accessibility Inspector. For the most part, it works well — it correctly displays warnings about missing button labels or insufficient touch target sizes. However, it does not seem to handle certain cases properly, particularly dynamic fonts. Here is the approach I’m using for dynamic fonts: static func getDynamic(font: FontType, size: CGFloat, textStyle: UIFont.TextStyle) -> UIFont { let customFont = UIFont(name: font.rawValue, size: size)! return UIFontMetrics(forTextStyle: textStyle).scaledFont(for: customFont) } label.adjustsFontForContentSizeCategory = true My labels are configured with: numberOfLines = 0 no fixed height constraints This allows them to expand as needed without clipping. I have tested this visually on multiple devices, and everything appears to work correctly — fonts scale as expected, and text is not truncated. However, Accessibility Inspector still reports issues related to dynamic type and, in some cases, text clipping. On iOS 18, approximately 40% of the fonts configured this way still trigger warnings about missing dynamic type support, even though they scale correctly. On iOS 26+, the issue becomes consistent — every font in the app triggers this warning. There are no cases where the inspector passes without reporting a problem, despite the UI behaving correctly in practice. So my question is: Is there a known way to resolve this? Could this be an issue with Apple's tools? If so, is there any information on when it might be fixed?

Hello, I am working on a research project focused on creating accessible interactions for visually impaired users. I need to verify some automated assistance processes in a real-world usage environment where VoiceOver is enabled. However, I have encountered a blocking issue: When I connect the device through Xcode UI Test / WebDriverAgent (or Appium + WDA) and perform operations, VoiceOver gets interrupted (sometimes it is even directly turned off), preventing blind users from continuing to use the narrator. Replication steps (stable replication)    On iPhone, enable VoiceOver (Settings → Accessibility → Narrator), and keep the device unlocked and the screen on. On Mac, start [Xcode UI Test / WebDriverAgentRunner / Appium+WDA] and establish a session with the device (XCTest session). Perform any operation: read the accessibility tree (/source), take screenshots, or click/slide. Observe the phenomenon: VoiceOver will [automatically turn off / reading interruption / focus jumping / unable to continue reading the new interface]. Expected behavior VoiceOver, as the core accessibility capability, should remain running and be able to continue reading the interface; the automation/assistance process should not "steal" and cause the narrator to fail. Actual behavior VoiceOver is [turned off / interrupted], and even after interface changes, it cannot read normally, affecting the use of blind users. I would like to ask: Non-jailbroken or external hardware-free methods Is this a known limitation (such as the mutual exclusion between XCTest and VoiceOver as Accessibility clients)? Is there an officially supported way to allow the automation/assistance program to safely read necessary information and trigger operations while VoiceOver is enabled, without disrupting the narrator (such as App Intents, Shortcuts, or other API/framework suggestions)? If it is necessary to avoid XCTest/WDA: In the research prototype stage, what is the recommended "reproducible, measurable" alternative technical route?

I am using Maestro framework for testing iOS. For our tests we need to save pdf's to files. When opening the 'QLOverlayDefaultActionButtonAccessibilityIdentifier' the buttons on the overlay are way off, the coordinates got corrupted. When opening the files app, the next screen has no coordinates for testing. I checked with xcode inspector and the same issue persists.

Hi, I have an app that displays lines of text, that I want to make accessible with VoiceOver. It's based on a UITextView. I have implemented the UIAccessibilityReadingContent protocol, following the instructions in https://developer.apple.com/videos/play/wwdc2019/248 and now users can see the screen line by line, by moving their fingers on the screen. That works fine. However, users would also like to be able to use left-flick and right-flick to move to the previous or next line on the screen, and I haven't been able to make this work. I can see that left-flick triggers accessibilityPreviousTextNavigationElement and right-flick triggers accessibilityNextTextNavigationElement, but I don't understand what these variables should be.

Scrivo questo post per farmi notare meglio, il 6 marzo ho mandato un feedback (poi aggiornato oggi, 18 marzo) tramite l‘app Feedback installata su iPhone chiedo a chiunque lavori all’interno di Apple, specialmente agli ingegneri informatici che si occupano delle funzioni di accessibilità di iOS 26 di visionare questo Feedback per aumentare ancora di più le opzioni di accessibilità degli utenti Apple, vi lascio di seguito l’ID del Feedback, grazie mille per il lavoro che fate FB22142615

Every new build of macOS 26 further breaks some part of text-to-speech or voice control. I have filed multiple bug reports on this, yet the situation gets worse, not better, with each new build. I am begging you to fix this! I am disabled and rely on these features to work. Accessibility in macOS is more than 50% of my reasons for choosing Macs over Windows. Here's some of what is currently broken: Speak announcements only works if the Samantha voice is selected. If other voices are selected either the announcements don't speak, or they default to the Samantha voice. This became broken with 26.1. Announce the time only works with some voices. I would like to use Australian English Siri 2 but with that voice selected it defaults to Samantha. This became broken with 26.4. With voice control enabled there are two menu bar icons. The blue voice control icon and an orange microphone "an application is accessing the microphone" icon. This orange icon started appearing with 26.3. For four years of macOS releases, the orange warning didn't apply to system services. And note that with voice control enabled on iOS there is no orange icon. It wastes valuable menu bar space and defeats its purpose. With that orange icon always being there I have no indication if a nefarious app starts recording me. This became broken with 26.3. Overlay shows numbers even when it is set to none. This has been broken since at least 14.0. I don't remember if it was broken in prior versions but it has been broken in every version since 14.0. The voice control control center widget is defective. If voice control is not in the menu bar (for example if I've said "Siri turn off voice control") using the control center widget to turn it on brings about the orange icon, but not the blue icon actually used for controlling voice control. If you do have the blue voice control icon and use control center to turn off voice control the blue icon stays but voice control is not enabled. This became broken in 26.0, was fixed in 26.2, broke again in 26.4. When using voice control to edit text (aka dictation mode) saying "go to the end of the line" invariably goes to the beginning of the line. Once in a blue moon it will go to the end, but there is no rhyme or reason and it's rare that it does. Since this bug was added it has worked correctly exactly twice. This became broken in 26.3 (possibly 26.4). I know I am missing some issues. Voice control and text-to-speech have new bugs with each new build of macOS 26. My main Mac is being repaired and once I get it back I'll be installing macOS 15 Sequoia on it because of these issues. These issues stop me from buying a new Mac because any new Mac will only run the broken macOS 26. I file bug reports on each build when I discover another new issue, but these reports seemingly go unread. I would suggest Apple get a focus group of disabled people together and do research into how we use macOS. Find what's broken and what works. And if Apple does this I would be glad to be a part of that group. My place, or yours. Accessibility at one time was something Apple was proud of. It was some Apple showed off. But now, I'm not so sure. It's starting to look like Apple doesn't care. I hope I'm wrong, and that Apple does care, so... Please, Apple. I am begging you. Fix broken Text-To-Speech and Voice Control!

Greetings! I'm facing a problem handleling full keyboard access in my app. This is a simpler version of the code: struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } .navigationTitle("Title n stuff") .padding() } } And the focus behaves as expected and the important thing, we can access que button on the right side of the screen But as soon as we introduce the scrollview, the right side button is unaccessible, since when we hit tab we go back to the back button in the nav stack header. struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { ScrollView { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } } .navigationTitle("Title n stuff") .padding() } } I've tried all the things I found online and none achieves an acceptable behavoir, I've seen ppl saying this issue has been fixed in ipados with the focusSection modifier, but I have not seen any fix fot this issue in ios.

We recently adopted our app to Liquid Glass and received a complaint from a visually impaired user that VoiceOver does not read out the number of unread items in the tab bar anymore. We checked and it seems that before iOS 26/Liquid Glass, setting a tab bar item's badgeValue property also set an appropriate text to its accessibilityValue property (something like "3 items"). But with Liquid Glass tab bars, this does not seem to be the case anymore. We fixed this by providing our own accessibility value, but we're wondering whether this change was a deliberate choice or simply a bug? If this new behavior is considered a bug, I would post a bug report.

Is there a way to extract the Accessibility Tree directly from the browser? Since Chrome provides an API for it, can we use that to generate a dump of the Accessibility Tree?