Better SwiftUI Support in Accessibility Audits

Question

Created 6h

Replies 1

Boosts 0

Participants 2

Will the Xcode accessibility audit tool be updated to better support SwiftUI?

I have simple cases where I have a Form section header 'Text("some text")' that clearly works in the real world and on simulators, but I have a warning for each such scenario.

Like compile warnings, too many incorrect warnings in the audit makes it hard to find the real potential accessibility issues.

Xcode: 27.1 RC

Here is a snippet from one of my audit reports. One of the warnings is pointing directly at the section header of my form. The code is as simple generic as one can get. As I mentioned the header is a simple Text("some text").

Screenshot 2026-10-15 at 10.00.34 AM.png

Screenshot 2026-10-15 at 10.01.55 AM.png

Answer 1

DTS Engineer OP

Apple

5h

hanks for creating a new post and the details. A list of Xcode version and build as well as the targeting OS version will be very helpful.

A few details that will help this post, a focused sample showing the issue as well as a list of the warnings you are receiving in Xcode. With the sample project I’m sure we will be able to see those warnings but provided the expected outcome helps to reproduce the issue.

I can't speak about future plans for Xcode as you know. So I can’t provide you an answer for that question.

A random thought and questions I had is the accessibility audit (performAccessibilityAudit() in XCUITest, and the Accessibility Inspector audit, work from the accessibility hierarchy that SwiftUI exposes at runtime. Section headers in a Form or List get the header trait from UIKit's backing views, so the audit does not see the way VoiceOver does?

Without the exact warning text, I can't even know where to go from here. If you post the exact warning message and the audit type, I can help work out whether it's a genuine issue and maybe a bug? I don’t know and can’t assume anything without that information.

Albert  WWDR