Input type for input fields

Screen reader, keyboard, and switch users depend on input fields declaring the correct input type to ensure that the right virtual keyboard appears, autofill for the input field works, and assistive technology can announce what kind of data the field is meant to collect. When a field’s declared type doesn’t match its actual purpose, users get the wrong keyboard, miss autofill suggestions, and receive weaker hints from the screen reader. This rule checks that every input field’s declared type, keyboard type, and autofill metadata correctly reflect the field’s intended input purpose.

Success criteria

The Issue Detection Agent flags the following potential violations:

• An input field uses the platform default input type, such as TYPE_CLASS_TEXT on Android or UIKeyboardType.default on iOS, instead of the input type that matches its purpose.
• An input field’s input type conflicts with its purpose. For example, a phone number field that is set to use an email keyboard.

AI-powered testing

The BrowserStack AI-powered Issue Detection Agent evaluates whether an input field’s declared type matches its intended purpose by conducting a multi-layered semantic analysis:

The Issue Detection Agent performs the following checks:

• Infers the field’s intended purpose:
  1. Reads the field’s visible label or name as the primary signal. The visible label takes precedence over the programmatic accessibility label.
  2. Uses the hint or placeholder text, neighboring label text, and sibling field labels, such as a sequence of Email, Phone, and OTP fields in a form, as supporting signals to determine what kind of data the field collects.
  3. Uses the accessibility label only as a fallback when no visible label is present.
  4. Evaluates labels in multiple languages. As a result, fields labeled Correo electrónico or Teléfono are correctly identified.
• Compares the inferred purpose against the declared type and autofill metadata:
  1. Flags fields whose purpose is clearly specialized, such as email, phone, number, date, OTP, or credit card, but whose declared type is the generic text default.
  2. Identifies fields where the keyboard type is correct but the autofill hint is absent or incorrect. This hint is autofillHints on Android and textContentType on iOS.
  3. Doesn’t flag fields whose purpose is genuinely free text, such as search, message body, or notes fields.
• Suggests the correct platform-specific corrections:
  1. Generates the input type and autofill hint that match the field’s purpose: inputType and autofillHints on Android, or keyboardType and textContentType on iOS.
  2. When the declared type is not available, such as in Flutter or custom widgets, suggests a type based on the inferred purpose and flags the field for your review.

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, ensure that you match the input type to the field’s purpose and set it correctly:

• For a specialized field, do not use the default input type. Instead, set the appropriate input type and autofill hint for the field’s purpose. For example, on Android, set inputType="textEmailAddress" and autofillHints="emailAddress" for an email field.
• If an input type conflicts with the field’s purpose, replace both the input type and the autofill hint with the correct values.
• For a field where only the keyboard type is set but the autofill hint is absent, add the corresponding autofill hint without changing the keyboard type.

Platform and framework specific fixes

The attribute that controls input type and autofill behavior varies by platform and framework. Apply the fix for your platform or framework:

AI-powered fix

You can also use the AI-powered suggestions to get the exact type and autofill hint values to set for each flagged field.

Example

The following example scan report shows an input type violation on the Social Media Details screen of an Android app:

Violation

• The Official Brochure PDF Link field expects a URL as the input, but the field has no declared input type.
• Without a URL input type, users get a standard keyboard instead of a URL-optimized keyboard. Additionally, assistive technology can’t determine the field’s expected input.

Fix

• Set android:inputType="textUri" so the URL keyboard appears and the field’s purpose is programmatically clear.

References

WCAG

• 1.3.5 Identify Input Purpose (Level AA): WCAG 2.1 · WCAG 2.2

RAAM 1.1

• 9.12: RAAM 1.1