Accessible input field labels

Screen reader users rely on an input field’s accessible name to understand what data to enter. TalkBack on Android and VoiceOver on iOS read this name aloud. When a label is missing, or when it is a generic value such as editText or field1, screen reader users can’t determine the field’s purpose. This rule checks that every input field has a meaningful, persistent label that accurately describes the expected input, and that apps don’t rely solely on placeholder text, which disappears when the user starts typing.

Success criteria

The rule checks for the following potential violations:

• An input field’s accessible name does not meaningfully describe its purpose.
• An input field has no label, placeholder, or value of any kind.
• An input field relies only on placeholder text, such as hint on Android, placeholder on iOS, or hintText on Flutter, which disappears once the user starts typing.
• An input field label repeats the field’s current value.

AI-powered testing

The BrowserStack AI-powered Issue Detection Agent evaluates whether an input field’s label meaningfully and persistently describes its purpose by conducting a multi-layered semantic analysis:

The Issue Detection Agent performs the following checks:

• Detects placeholder-only labels:
  • Identifies fields where only a placeholder is present and no persistent label is set, regardless of how descriptive the placeholder text is.
• Evaluates label meaningfulness in context:
  1. Reads the field’s surrounding context to assess whether an ambiguous label becomes meaningful in context.
  2. Identifies if there is a mismatch between the programmatic accessible name and the visible on-screen label, or between the label and the field’s declared input type. For example, a password field labeled Phone number.
  3. Recognizes a standard icon near a field, such as a search icon, that conveys the field’s purpose. A field whose purpose is clear from a well-known icon isn’t flagged, even without a text label.
  4. Evaluates labels in multiple languages.
• Suggests persistent, descriptive labels:
  1. Generates a label that reflects the field’s purpose and input type.
  2. When the programmatic label and the visible label differ, the suggestion includes a note to align both.
  3. When only a placeholder exists, the agent suggests a persistent label, not a replacement placeholder.

For more information, see Issue Detection Agent.

How to fix

You can fix violations manually or by applying the AI-powered fix.

Manual fix

To fix a violation, give the input field a persistent, descriptive label that matches its purpose:

• Replace a generic label such as editText or field1 with a label that describes the expected input, such as Email address or Phone number.
• Replace the placeholder for a field with a persistent visible label that stays visible even after the user begins typing, and associate it programmatically with the input field.
• If the visible label and the programmatic accessible name differ, update both so they are consistent with each other and with the field’s input type.
• If the field’s current value is used as its accessible name, set a descriptive accessibilityLabel on iOS or contentDescription on Android that describes the field’s purpose instead.

Platform and framework specific fixes

The element that represents an input field, and the attribute that carries its accessible name, vary by platform and framework. Apply the fix for your platform or framework:

AI-powered fix

You can also use the AI-powered suggestions to ensure that all input fields have meaningful, persistent labels that accurately reflect their purpose.

Example

The following example scan report shows accessible input field label violations on the Profile information screen of an iOS app:

Violation

• One field shows the entered text they/them but has no label, so a user relying on a screen reader can’t tell that the field collects pronouns.
• The other field has no descriptive label either. Its only label repeats the entered text Loves trail runs, so a user relying on a screen reader can’t tell that the field is for a short bio.

Fix

• Set a descriptive accessibilityLabel on each field that states its purpose, such as Pronouns and Bio.
• Do not use the user’s entered value as the label.

References

WCAG

• 1.3.5 Identify Input Purpose (Level AA): WCAG 2.1 · WCAG 2.2
• 2.4.6 Headings and Labels (Level AA): WCAG 2.1 · WCAG 2.2
• 2.5.3 Label in Name (Level A): WCAG 2.1 · WCAG 2.2
• 3.3.2 Labels or Instructions (Level A): WCAG 2.1 · WCAG 2.2

RAAM 1.1

• 9.1: RAAM 1.1
• 9.2: RAAM 1.1
• 9.3: RAAM 1.1
• 9.4: RAAM 1.1