Skip to content

fix: toBeDisabled now also evaluates disabled prop when element is Text #1802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rarenatoe
Copy link

@rarenatoe rarenatoe commented Jul 24, 2025

Summary

Resolves #1801 by ensuring Text components with the disabled prop are correctly identified as disabled by computeAriaDisabled.

Previously, computeAriaDisabled didn't check for the disabled prop on Text elements, causing queries like getByRole('text', { disabled: true }) to fail. The change adds a check to return true when isHostText(element) and props.disabled are both true, aligning react-native-testing-library's behavior with expected accessibility states.

Test plan

New unit tests have been added for computeAriaDisabled to verify this change. These tests cover:

  1. Text component with disabled={true}: Asserts computeAriaDisabled returns true.

  2. Text component without disabled prop or disabled={false}: Asserts computeAriaDisabled returns false.

  3. Existing TextInput behavior: Ensures non-editable TextInput components are still correctly identified as disabled.

  4. aria-disabled and accessibilityState.disabled props: Verifies these existing checks continue to function.

The new computeAriaDisabled tests should pass, demonstrating correct handling of the disabled prop on Text components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

toBeDisabled() matcher behavior with Text component and onPress/disabled props
1 participant