The question often asked in the mobile development community is, "I want to be able to add accessibility to my regression tests, but is there a way to do it?". There have been many open source projects created in the past that have allowed for it, but most of them either have stopped having support or are out of date.

Since Xcode 15, performAccessibilityAudit() is now a function that is readily available for use within XCUI tests! It runs the same automated checks as the "Accessibility Inspector" and allows for consistent regression of accessibility issues. So how do we make the most of it? Let's check it out!

Setting it up

The simple answer to setting it up is, if you have an XCTestCase using XCUIApplication() then you can call performAccessibilityAudit() on your content!

final class accessibilityAuditExample: XCTestCase {

    var app: XCUIApplication!

       override func setUpWithError() throws {
           continueAfterFailure = true
           app = XCUIApplication()
           app.launch()
       }

It can be triggered on any XCUIElement, which means you can scope your checks to the entire app, a specific screen, or a single component.

Performing the Audit

To have the audit be performed on the current application screen, simply call 'app.peformAccessibilityAudit()'.

Here is a simple example of setting up an application, and then performing an audit on the home screen:

//Performing Accessibility Audit on Login Screen
func testLoginScreenAccessibilityAudit() throws {
        XCUIApplication().tabBars.buttons["Home"].tap()
        try app.performAccessibilityAudit()
 }

Test Case Setup

With the ease of using the accessibility audit functionality, you can decide how you want to do the testing. There are multiple ways in which you can set it up:

Accessibility has its own test suite

Instead of doing regression tests as part of the usual suite of tests, you would make accessibility test suite that runs through the application and ONLY tests that content. (do not recommend, however there are reasons to do so)

Each XCTestCase has its own accessibility test

For each XCTestCase there is a test for accessibility (or multiple) that live with the rest of the tests. This is a great way to integrate accessibility as part of the normal regression testing process, while also calling out accessibility as its own test.

Accessibility test is added to each test case

Instead of making separate tests for accessibility, simply add it in as part of another test case. For example, if you were testing the functionality of a login screen (entering text, error messaging, etc.) and then during that you would run an audit for each stage!

Data and Results

When the test case has been completed, you can see the results in multiple different ways. In the test navigator, if you click on fail test case it will take you to where the issue is and showcase the issues found in line in the code with the test

The other way is to go to the report navigator, and under tests you will see the issues found with their descriptions.

In Summary

Bringing the Accessibility Inspector functionality into your XCUI test suite gives your team a first‑party, reliable, and maintainable way to catch accessibility regressions automatically.

By integrating audits directly into your existing XCTestCases, accessibility stops being an afterthought and becomes part of the natural development and QA process. It’s simple, built‑in, and it finally gives iOS teams a dependable path to automated accessibility regression testing.

To see a full working example, checkout the iOS Automated Accessibility Library