Photo by Balázs Kétyi on Unsplash

How to Run a Mobile App Accessibility Audit Without Missing Critical Issues

The first mobile app accessibility audit I led was far more intimidating than I expected. I knew the basics, and had a list of accessibility requirements from the product team. Yet I still wasn’t sure where to begin.

Over the years, I’ve developed multiple checklists to run a systematic mobile app accessibility audit without letting critical issues slip through. I build it into the testing workflow we use for every major release. In this article, I’ll walk you through my process. I’ll also share how I deal with common issues, and the tools I like.

What Is a Mobile App Accessibility Audit?

A mobile app accessibility audit is a comprehensive evaluation of a mobile app to ensure it can be used by people with disabilities. It’s basically a thorough test of the user journey.

Accessibility Scans vs. Accessibility Auditing

Think of an accessibility scan as your first line of defense. Automated tools identify obvious issues like missing accessibility labels, poor color contrast, duplicate labels, or touch targets that don’t meet platform guidelines.

An accessibility audit goes much further. After running automated scans, I manually navigate the app using screen readers, increase the system font size, test different accessibility settings, and validate the complete user journey on real devices. This is where issues like incorrect focus order, inaccessible custom controls, confusing announcements, or focus traps emerge.

Accessibility scans answer: “Does the UI violate common accessibility rules?”

Accessibility audits answer: “Can a person with disabilities use this app independently?”

WCAG, ADA, EAA, and Platform Guidelines

Every accessibility audit needs a benchmark. These are the standards QA teams should be acquainted with:

• WCAG 2.1/2.2 Level AA: The baseline most organizations use for evaluating mobile accessibility. Although written for the web, the POUR principles: Perceivable, Operable, Understandable, and Robust, apply directly to native mobile apps.
• ADA (Americans with Disabilities Act): This US law requires public and private entities to offer equal access to goods and services. While written before the internet, US courts have largely applied Title III to websites and mobile apps. It is driven by private litigation and there is no “safe harbor”; however, organizations typically aim for WCAG 2.1 AA to defend against lawsuits.
• European Accessibility Act (EAA): This EU directive covers a range of digital and physical products, including e-commerce platforms, banking services, and self-service kiosks. Compliance is determined by where your customers are, not where your business is headquartered. It relies on conformance with the EN 301 549 standards, which incorporate WCAG.
• Platform-specific guidance: Apple’s Human Interface Guidelines and Google’s Material Design Accessibility translate WCAG into platform-specific recommendations, covering areas such as touch target sizes, accessibility labels, focus behavior, and dynamic text.

Once you’ve established the standards your audit needs to satisfy, the next step is deciding what kind of audit you’re actually running. A quick development check requires a very different approach from a formal compliance review.

Types of Accessibility Audits

I don’t run the same accessibility audit every time. The scope depends on where the app is in its lifecycle and what I’m trying to achieve.

• Development audits: These happen while features are still being built. Developers and QA use platform tools and automated scanners to catch obvious issues before code reaches the main branch.
• Regression audits: Once accessibility bugs have been fixed, add automated accessibility checks to the CI/CD pipeline. The goal: prevent future releases from reintroducing problems that have already been addressed.
• Compliance audits: These are comprehensive, end-to-end evaluations performed before a major release or certification effort. Every critical user journey is tested against standards such as WCAG 2.2 AA, with detailed documentation of findings and remediation recommendations.
• Third-party audits: For products with strict accessibility requirements, I recommend an independent review. External accessibility specialists, and people who regularly use assistive technologies, often uncover usability issues that internal teams overlook because they’re too familiar with the product.

Knowing which type of audit you’re performing helps you choose the right tools and set realistic expectations.

How I Run a Mobile Accessibility Audit (Travel Booking App Example)

Step 1: Define the Critical User Journey

One mistake I see teams make is trying to audit every screen equally. Start with the user journeys that directly impact customers and the business. For a travel booking app, that means:

• Search flights from New York to San Francisco
• Select travel dates
• Choose seats
• Add baggage
• Enter passenger details
• Complete payment
• View booking confirmation

This journey covers most common accessibility challenges in a modern mobile app: search fields, date pickers, complex seat maps, dialogs, forms, dynamic pricing, and confirmation screens.

Step 2: Catch the Obvious Issues First

Once the journey is defined, I let automation remove as much manual effort as possible.

On Android, enable Espresso Accessibility Checks so every UI test automatically validates accessibility whenever it interacts with the interface.

import androidx.test.espresso.accessibility.AccessibilityChecks import org.junit.BeforeClass class BookingFlowTest

{

companion object

{ @BeforeClass @JvmStatic fun enableAccessibilityChecks()

{ AccessibilityChecks.enable() .setRunChecksFromRootView(true)

} } }

On iOS, I add accessibility assertions for critical controls using XCUITest.

func testAccessibilityOnCheckout() {

let app = XCUIApplication() app.launch()

do {

try app.performAccessibilityAudit()

} catch

{ XCTFail(“Accessibility audit failed: \(error.localizedDescription)”)

} }

This step uncovers the easy wins, such as:

• Missing accessibility labels
• Touch targets that don’t meet platform recommendations
• Duplicate accessibility labels
• Low color contrast
• Hidden interactive elements

These are inexpensive to fix, so resolve them before investing time in manual testing.

Step 3: Navigate the Journey with a Screen Reader

Once the automated issues are out of the way, I turn on TalkBack or VoiceOver and complete the entire booking flow without relying on the screen. This is where accessibility testing becomes very different from functional testing.

As I move through the booking flow, I’m asking questions like:

• Does the date picker announce each date correctly?
• Can I navigate the seat map logically?
• Does TalkBack announce whether a seat is available, occupied, or already selected?
• Can I move in and out of the baggage selection dialog without getting trapped?
• Are pricing updates announced when I add a checked bag?

In one audit, everything looked perfect visually, but TalkBack couldn’t communicate seat availability because every seat was announced simply as “Button.” A screen reader user had no way of knowing which seats were available or premium.

Step 4: Stress the Interface

At this point, I know the app works. Now I want to know whether it still works when users rely solely on accessibility features.

I deliberately push the interface to its limits and repeat the same booking journey looking for failures that functional testing rarely uncovers.

• Increase text to the maximum size. Verify that fares, passenger details, and action buttons remain readable. Watch for clipped text, overlapping UI elements, or buttons like Continue to Payment disappearing below the fold.
• Enable display zoom or screen magnification. Navigate through the flight search, seat selection, and payment screens while zoomed in. Users shouldn’t have to pan horizontally just to read a fare or complete a form, and key actions should remain easy to locate.
• Remove color as a cue. Turn on grayscale or color correction and check whether important information is still understandable.
• Navigate without touching the screen. Using a hardware keyboard or Switch Access, move through the booking flow using only focus navigation. Every interactive element should be reachable in a logical order, clearly highlighted, and fully operable.

Step 5: Validate on Real Devices

This is the step I never skip, especially for Android. Unlike iOS, Android runs across hundreds of device models, multiple OS versions, and customized manufacturer skins.

Get Jenny Keeper’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

More importantly, I don’t choose devices randomly.

My device matrix is driven by analytics. I look at the Android versions, manufacturers, and screen sizes the customers use, then prioritize testing on those devices. If analytics show growing adoption of foldables, they become part of the audit as well.

Step 6: Turn Findings into Regression Tests

Every issue my team resolves becomes a regression test.

If we fix a missing accessibility label on the Book Flight button or correct the focus order in the seat selection screen, I make sure that validation becomes part of our automated test suite. Otherwise, there’s a good chance the same issue will reappear a few sprints later.

Mobile App Accessibility Audit Tools I’ve Used

Below, I cover the tool stack I’ve chosen and deployed over several projects.

Native Platform Tools

Apple Accessibility Inspector

When I’m auditing an iOS app, Accessibility Inspector is the first tool I open. Since it’s built into Xcode, developers can inspect accessibility properties without leaving their development environment.

Best for

• Inspecting the accessibility tree
• Verifying labels, traits, and hints
• Checking color contrast
• Debugging accessibility issues during development

Google Accessibility Scanner

Accessibility Scanner is my quickest way to catch obvious accessibility issues on Android before I start manual testing.

After launching the app on a real device, I scan each screen in the critical user journey. Within seconds, it flags problems like missing content descriptions, touch targets smaller than 48 x 48 dp, insufficient color contrast, and duplicate labels.

One feature I particularly like is workflow auditing. Rather than scanning individual screens in isolation, Accessibility Scanner can record an entire user journey and generate a consolidated report across multiple screens. That’s especially useful when auditing flows.

Best for

• Detecting missing labels and small touch targets
• Measuring color contrast
• Auditing complete user journeys
• Giving developers actionable recommendations before manual testing

Keep in mind: Accessibility Scanner tells you what violates accessibility guidelines, but not whether users can complete the task. That’s why I always follow it with TalkBack testing.

Automated Testing Frameworks

Accessibility Test Framework (Android)

Once obvious issues are fixed, I don’t want them coming back. That’s where Google’s Accessibility Test Framework (ATF) comes in. ATF integrates with Espresso and automatically checks accessibility whenever your UI tests run. Enabling it takes a few lines of code:

import androidx.test.espresso.accessibility.AccessibilityChecks

@BeforeClass

@JvmStatic

fun setupAccessibilityChecks() {

AccessibilityChecks.enable()

.setRunChecksFromRootView(true)

}

Running these checks in CI/CD has saved my team from shipping regressions like missing content descriptions, duplicate labels, and inaccessible touch targets after unrelated UI changes.

XCUITest Accessibility Checks

Unlike Espresso, XCUITest doesn’t automatically audit accessibility. Instead, write assertions for the UI elements that matter most.

For example, if a user can’t activate the Book Flight button using VoiceOver, that’s a release blocker. I make those checks part of the automated suite.

let bookButton = app.buttons[“Book Flight”] XCTAssertTrue(bookButton.exists) XCTAssertEqual(bookButton.accessibilityLabel, “Book Flight”)

Focus on validating the accessibility of critical actions while leaving usability testing to manual VoiceOver sessions.

Cross-Platform Audit Tools

BrowserStack App Accessibility

Native tools become much harder to manage when you need to validate accessibility across dozens of Android devices, iPhone models, and OS versions before release.

BrowserStack App Accessibility fills that gap by letting my team run accessibility tests on real Android and iOS devices in the cloud. Instead of relying on an in-house device lab, we validate accessibility across the mix of devices our customers typically use.

Best for

• Real-device accessibility testing at scale
• Validating TalkBack and VoiceOver across different devices
• Testing representative Android and iOS device matrices
• Sharing centralized accessibility reports with engineering and compliance teams

Which Tool Is Best for Developers, QA Engineers, and Compliance Teams?

If I had to recommend one starting point for each role, it would be this:

• Developers: Apple Accessibility Inspector and Google Accessibility Scanner to catch issues while building features.
• QA engineers: Accessibility Test Framework (Android), XCUITest assertions, and manual TalkBack/VoiceOver testing to validate complete user journeys.
• QA leads and compliance teams: BrowserStack App Accessibility for large-scale real-device testing, centralized reporting, and release readiness across multiple devices and operating systems.

Common Accessibility Issues I’ve Found During Audits

No matter the app or industry, these are the issues that are very common:

• Touch targets that are too small: Buttons and icons don’t meet the minimum size recommendations (44 x 44 pt on iOS, 48 x 48 dp on Android), making them difficult for users with motor impairmen
• Missing or redundant accessibility labels: Screen readers announce controls as “Button” or “Unlabeled”, or labels are overly verbose (for example, “Submit Button” instead of simply “Submit”).
• Incorrect roles or traits: Custom components behave like buttons, checkboxes, or tabs visually but aren’t exposed correctly to VoiceOver or TalkBack, so users don’t know they’re interactive.
• Broken focus order: Keyboard, Switch Access, or screen reader focus jumps unpredictably, skips controls, or gets trapped inside dialogs and bottom sheets.
• Low color contrast: Text and icons don’t meet WCAG contrast requirements, making them difficult to read in different lighting conditions or for users with low vision.
• Dynamic text failures: Increasing the system font size causes text to overlap, truncate, or push important actions like Continue or Book Flight off-screen.
• State changes aren’t announced: Screen readers don’t notify users when actions occur, such as adding baggage, selecting a seat, or completing payment.
• Accessibility regressions: Previously fixed issues reappear after UI updates because accessibility checks weren’t added to the automated regression suite.

What To Do After the Accessibility Audit

• Prioritize by user impact. Not every accessibility issue deserves the same urgency.
• Write developer-ready bug reports. Instead of reporting “TalkBack doesn’t work on checkout,” explain exactly what failed.
• Suggest the fix whenever possible. Point developers toward the relevant WCAG criterion or platform guidance, and include screenshots or screen recordings if the issue is difficult to reproduce.
• Validate the fix manually. After the issue is resolved, repeat the same user journey with TalkBack or VoiceOver to confirm the experience has actually improved.

Conclusion

One area I’m increasingly experimenting with is AI. Rather than replacing manual testing, AI agents can act almost like another QA teammate. They can simulate different user personas, identify likely accessibility violations, suggest fixes, and help prioritize areas that deserve deeper manual investigation.

Once you have a repeatable accessibility workflow, they become just another part of shipping quality software. Ultimately, the goal of a mobile accessibility audit isn’t to achieve a perfect compliance score. It’s to ensure every user can complete the journeys your app was built for. Improving accessibility helps all users and grows your business as a result. Not only that, good accessibility practices can prevent costly lawsuits.