enabling-accessibility-checks

Enable Espresso AccessibilityValidator checks against the Compose semantics tree in Android UI tests.

303|10|Updated May 15, 2026
One-click install
npx skills add https://github.com/skydoves/android-testing-skills --skill enabling-accessibility-checks
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: enabling-accessibility-checks
Source: https://github.com/skydoves/android-testing-skills/tree/main/compose/debug/enabling-accessibility-checks
Command: npx skills add https://github.com/skydoves/android-testing-skills --skill enabling-accessibility-checks

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you catch accessibility regressions in Jetpack Compose UI tests by enabling Espresso’s AccessibilityValidator to validate the Compose semantics tree.

Core Features & Use Cases

  • Enable validation against the Compose semantics tree: Uses enableAccessibilityChecks(...) to run accessibility checks before every UI-mutating action in Compose tests.
  • Configure strict failure behavior: Lets you switch from warning-only results to throwing exceptions on ERROR using a configured AccessibilityValidator.
  • Works for hybrid Compose + Views: Shares one validator instance with Espresso via AccessibilityChecks.enable() so both layers report consistently.

Quick Start

Use the enabling-accessibility-checks skill to add enableAccessibilityChecks() to your Compose test on a real device running API 34+.

Frequently Asked Questions about enabling-accessibility-checks

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run Espresso accessibility checks on a Jetpack Compose semantics tree?

To run Espresso accessibility checks on a Jetpack Compose semantics tree, enable accessibility validation by calling enableAccessibilityChecks() in your Compose UI tests running on an API 34+ device. This applies the AccessibilityValidator to UI-mutating actions.

Can I catch Compose accessibility regressions as errors instead of warnings?

You can catch Compose accessibility regressions as strict errors by configuring an AccessibilityValidator to throw exceptions on ERROR results, moving beyond warning-only outputs to actively gate your UI tests against accessibility failures.

Does Compose accessibility validation work for hybrid apps with both Compose and Android Views?

Compose accessibility validation works for hybrid apps by sharing a single AccessibilityValidator instance with Espresso via AccessibilityChecks.enable(), ensuring both the Compose semantics tree and Android View layers report accessibility issues consistently.

What Android API level is required to enable Compose accessibility validation?

Enabling Compose accessibility validation requires a real device or environment running Android API 34 or higher, because the underlying Espresso AccessibilityValidator relies on platform features introduced in that API level to inspect the semantics tree.

Are Robolectric test results reliable for Compose accessibility checks?

Robolectric test results for Compose accessibility checks are treated as inconclusive, meaning you must run your ComposeUiTest and AndroidComposeTestRule suites on a real device or emulator with API 34+ support to validate accessibility regressions accurately.

Do I need to manually trigger accessibility checks after performMultiModalInput in Compose UI tests?

Manual accessibility checks are required after calling performMultiModalInput and requestFocus in Compose UI tests, because the AccessibilityValidator does not automatically validate these specific UI-mutating actions within the semantics tree.