Skip to content

Accesible Label on TextInput #4914

Description

@Balazs-Dee

My Problem:
Currently, there is no streamlined way to provide a custom accessibility label specifically for the TextInput label or to override how screen readers announce "required" fields.

When a label uses a visual indicator like an asterisk (e.g., E-Mail *), VoiceOver reads it literally as "E-Mail Star" or "E-Mail Asterisk". This is confusing for users; the screen reader should ideally announce the semantic intent: "E-Mail, required."

Suggested solution:
I propose adding an accessibilityLabel (or labelAccessibilityLabel) prop to the TextInput component.

Behavior: If provided, this string would be used by the screen reader to identify the field, allowing developers to pass "E-Mail, required" while keeping the visual label as "E-Mail *".

Implementation: This prop should map directly to the underlying native accessibility labels (accessibilityLabel on React Native or aria-label on Web).

Alternatives you've considered
I have attempted several workarounds with limited success:

Custom Label Component: Passing a custom Text component with accessibilityLabel and accessible={true}.

Visually Hidden Text (SR-Only): Wrapping two components in a View—one visually hidden for screen readers containing the "Required" text, and one visible to sighted users with importantForAccessibility="no-hide-descendants".

Activity

  1. self-assigned this
    on May 10, 2026
  2. huytdps13400 commented on Aug 26, 2026

    @huytdps13400

    I traced this against current main at dfaecf05bf5aa23d06502048b7bfb3b2150c11bc. The requested behavior is already available through the library's current accessibility convention: TextInputProps extends React Native's native TextInputProps, and the rendered input spreads Paper's generated accessibility data before consumer props. As a result, <TextInput label="E-Mail *" aria-label="E-Mail, required" /> keeps the visual label while the consumer-provided aria-label overrides the generated label for the native input and web. This also matches the maintainer-approved migration in #5005, which standardized Paper on aria-* props. Adding a separate labelAccessibilityLabel prop would duplicate the existing API. If this still reproduces, could you confirm whether you need the behavior backported to the 5.x line rather than current 6.x main?

  3. Balazs-Dee commented on Sep 2, 2026

    @Balazs-Dee
    Author

    @huytdps13400 thanks for the response. So in 5.15 definitely not working. We plan to upgrade soon to the current 6.x version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions