mobile-a11y-test-author

Use when an iOS or Android app needs accessibility tests: XCUITest performAccessibilityAudit (iOS 17+), VoiceOver labels and traits, Espresso AccessibilityChecks, Accessibility Scanner and TalkBack order, plus WCAG checks for labels, 44pt and 48dp touch targets, contrast and focus order.

/plugin install qa-mobile@testland-qa

First time in Claude Code? Add the marketplace with /plugin marketplace add testland/qa

View source (opens in a new tab)

Overview

Native mobile accessibility testing spans two complementary layers:

  • Automated audits catch structural issues (missing labels, contrast failures, undersized tap targets) on every CI run.
  • Assistive-technology checks (VoiceOver, TalkBack) verify what automation cannot observe: announcement order, gesture navigation, hint clarity.

This skill covers both layers on iOS and Android. Full per-platform detail lives in references/ios-audit.md and references/android-checks.md.

Nearest neighbors and differentiation:

  • xcuitest-suite - general XCUITest UI automation; does not cover performAccessibilityAudit, VoiceOver traits, or touch-target checks.
  • espresso-suite - general Espresso UI automation; does not wire AccessibilityChecks, Accessibility Scanner, or TalkBack workflows.

When to use

  • An iOS or Android app needs accessibility (a11y) test coverage.
  • The team must verify WCAG-aligned requirements (labels, contrast, touch targets, focus order) on real or simulated devices.
  • A screen-reader regression (VoiceOver, TalkBack) has been reported and needs a test that guards against recurrence.

iOS - core audit

performAccessibilityAudit() (iOS 17+) audits the current view and fails the test automatically if any issue is found - no explicit assertion needed (wwdc23 (opens in new window)).

import XCTest

final class HomeAccessibilityTests: XCTestCase {
    override func setUpWithError() throws {
        continueAfterFailure = true   // report ALL issues per screen, not just the first
        XCUIApplication().launch()
    }

    func testHomeScreenAudit() throws {
        try XCUIApplication().performAccessibilityAudit()
    }
}

Scoped audits, false-positive suppression, audit-per-screen, VoiceOver label/trait/hint checks, 44pt touch targets, and Accessibility Inspector are in references/ios-audit.md.

Android - core checks

AccessibilityChecks.enable() fires the Accessibility Test Framework on every Espresso perform() call; setRunChecksFromRootView(true) checks the whole hierarchy, not just the interacted view (atf (opens in new window)). Requires the espresso-accessibility dependency.

import androidx.test.espresso.accessibility.AccessibilityChecks

@RunWith(AndroidJUnit4::class)
class CheckoutAccessibilityTest {
    init {
        AccessibilityChecks.enable().setRunChecksFromRootView(true)
    }

    @Test
    fun applyPromoCode() {
        onView(withId(R.id.promo_field)).perform(typeText("WELCOME10"), closeSoftKeyboard())
        onView(withId(R.id.apply_button)).perform(click())
        // checks fire automatically on every perform()
    }
}

The dependency, suppression, 48dp touch targets, contrast thresholds, contentDescription labelling, and the TalkBack manual workflow are in references/android-checks.md.

CI integration

iOS (GitHub Actions)

jobs:
  a11y-audit:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v5
      - run: |
          xcodebuild test \
            -project MyApp.xcodeproj \
            -scheme MyApp \
            -destination 'platform=iOS Simulator,name=iPhone 15,OS=latest' \
            -only-testing MyAppUITests/HomeAccessibilityTests \
            -resultBundlePath A11yResults.xcresult
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: a11y-xcresult
          path: A11yResults.xcresult

Android (GitHub Actions)

jobs:
  a11y-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 34
          script: ./gradlew connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=com.example.CheckoutAccessibilityTest
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: a11y-test-results
          path: app/build/outputs/androidTest-results

Anti-patterns

Anti-patternWhy it failsFix
continueAfterFailure = false in audit testsStops after the first issue; misses the rest on the same screenSet continueAfterFailure = true for audit tests (wwdc23 (opens in new window))
No suppression closure; globally ignoring an audit typeHides all failures of that type, not just the known oneSuppress by both auditType and element.label (references/ios-audit.md)
Setting accessibilityLabel to the element type"Submit button" - VoiceOver already announces "button" from traitsSet label to purpose only: "Submit order" (uia (opens in new window))
contentDescription on every Text composableRedundant; TalkBack reads text content automaticallyOmit for plain text; set only for icon-only or image elements (cd (opens in new window))
Running AccessibilityChecks without setRunChecksFromRootView(true)Checks only the interacted view; off-screen violations passEnable root-view mode (Android core, above) (atf (opens in new window))
Manual TalkBack only, no automated checksInconsistent; regressions slip in on refactorsPair TalkBack manual review with AccessibilityChecks in CI

Limitations

  • performAccessibilityAudit requires iOS 17+. For pre-17 targets write explicit XCUIElement.label and frame assertions (see references/ios-audit.md).
  • Automated audits do not replace assistive-technology testing. The WWDC 2023 session explicitly states they are not a substitute for testing with VoiceOver or Dynamic Type enabled (wwdc23 (opens in new window)).
  • AccessibilityChecks fires on perform() only. Views that are visible but never interacted with in a given test are not checked unless setRunChecksFromRootView(true) is set.
  • Contrast checks require rendered colors. Dynamic themes or custom draw code may produce contrast failures only at runtime; static analysis tools (Android Lint) cannot catch them.

References

Reference

Android accessibility test detail

View source (opens in a new tab) (opens in new window)

Extends the core AccessibilityChecks.enable() example in ../SKILL.md (opens in new window). Checks run automatically on any ViewActions action and cover the acted-on view plus all descendant views (atf (opens in new window)).

Add the dependency

// app/build.gradle
dependencies {
    androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.6.1'
}

Enable checks from the root view

import androidx.test.espresso.accessibility.AccessibilityChecks

@RunWith(AndroidJUnit4::class)
class CheckoutAccessibilityTest {
    init {
        AccessibilityChecks.enable().setRunChecksFromRootView(true)
    }

    @Test
    fun applyPromoCode() {
        onView(withId(R.id.promo_field)).perform(typeText("WELCOME10"), closeSoftKeyboard())
        onView(withId(R.id.apply_button)).perform(click())
        // checks fire automatically on every perform()
    }
}

setRunChecksFromRootView(true) evaluates the whole hierarchy, not just the interacted view (atf (opens in new window)).

Suppress known issues

AccessibilityChecks.enable().apply {
    setSuppressingResultMatcher(
        allOf(
            matchesCheck(TextContrastCheck::class.java),
            matchesViews(withId(R.id.decorative_watermark))
        )
    )
}

The matcher must satisfy both the check type and the specific view (atf (opens in new window)).

Touch target size (48dp minimum)

Each interactive UI element should have a focusable area of at least 48dp x 48dp (atgt (opens in new window)). AccessibilityChecks validates this on every perform() call.

Contrast thresholds

AccessibilityChecks (via the Accessibility Test Framework) checks these on every perform() call (contrast (opens in new window)):

  • Text smaller than 18sp, or bold text smaller than 14sp: minimum contrast ratio 4.5:1.
  • All other text: minimum contrast ratio 3:1.

contentDescription labelling

Convey purpose, not visual detail (cd (opens in new window)):

// Icon-only button: set contentDescription
Icon(
    imageVector = Icons.Filled.Share,
    contentDescription = stringResource(R.string.label_share)
)

// Decorative image: suppress from accessibility
Icon(
    imageVector = Icons.Filled.Decoration,
    contentDescription = null   // TalkBack skips this element
)
  • Text composables need no contentDescription; TalkBack reads text content automatically.
  • List items need distinct descriptions so a screen reader does not repeat the same label.

Verify with Espresso:

onView(withId(R.id.share_button))
    .check(matches(withContentDescription(R.string.label_share)))

TalkBack manual workflow

Enable via Settings > Accessibility > TalkBack > On, then (at (opens in new window)):

  1. Linear navigation: swipe right/left through elements in order; double-tap to activate.
  2. Explore by touch: drag to hear elements under your finger.

Manual checklist:

  • All interactive elements are reachable via swipe.
  • Each element announces its purpose clearly and without redundancy.
  • Alert messages are announced when they appear.
  • Focus traversal order matches the visual reading order.

References

Extends the core performAccessibilityAudit() example in ../SKILL.md (opens in new window). The audit is available from iOS 17 and fails the test automatically when it finds an issue, so no explicit assertion is needed (wwdc23 (opens in new window)).

Scope the audit to specific categories

try app.performAccessibilityAudit(for: [.dynamicType, .contrast])

Pass an XCUIAccessibilityAuditType option set. Documented audit types include .dynamicType and .contrast; passing no argument runs all available checks (wwdc23 (opens in new window)).

Suppress known false positives

try app.performAccessibilityAudit(for: [.contrast]) { issue in
    // Ignore the decorative watermark label (no contrast fix planned)
    if let element = issue.element,
       element.label == "WatermarkLabel",
       issue.auditType == .contrast {
        return true   // suppress this issue
    }
    return false
}

The closure receives an XCUIAccessibilityAuditIssue; return true to suppress. Narrow suppressions by both auditType and element.label so real regressions still fail (wwdc23 (opens in new window)).

Cover each screen

Each call inspects only the currently visible elements. Navigate to every distinct screen and re-run the audit:

func testCheckoutFlowAudit() throws {
    let app = XCUIApplication()
    app.launch()
    try app.performAccessibilityAudit()          // Screen 1
    app.buttons["place-order-button"].tap()
    try app.performAccessibilityAudit()          // Screen 2
}

VoiceOver label, trait, and hint checks

accessibilityLabel is the localized string VoiceOver reads to identify an element, accessibilityHint describes the action result, and accessibilityTraits communicates purpose - common values are .button, .link, .header, .image, .staticText, .adjustable (uia (opens in new window)). Production code sets them; XCUITest verifies via XCUIElement.label:

// Production (UIKit)
let submitButton = UIButton()
submitButton.accessibilityLabel = "Submit order"
submitButton.accessibilityHint  = "Places your order and charges the saved card"
submitButton.accessibilityTraits = [.button]
// Test
func testSubmitButtonLabel() {
    let btn = XCUIApplication().buttons["Submit order"]
    XCTAssertTrue(btn.exists, "VoiceOver cannot find the Submit button")
    XCTAssertEqual(btn.label, "Submit order")
}

Touch target size (44pt minimum)

The minimum control size on iOS and iPadOS is 44x44 pt (hig (opens in new window)). Assert via XCUIElement.frame:

func testSubmitButtonTouchTarget() {
    let frame = XCUIApplication().buttons["Submit order"].frame
    XCTAssertGreaterThanOrEqual(frame.width,  44, "Touch target width below 44pt")
    XCTAssertGreaterThanOrEqual(frame.height, 44, "Touch target height below 44pt")
}

Accessibility Inspector (manual complement)

Open it from Xcode menu > Open Developer Tool > Accessibility Inspector. It runs the same checks as performAccessibilityAudit() interactively on real devices and simulators - use it to diagnose an audit failure before writing a suppression (wwdc23 (opens in new window)).

References