Mobile Accessibility Guidelines - Forms

Input format must

A default input format must be indicated and supported.

Labels help all users to understand what a form control is and what is being asked for. And they are essential for users who cannot easily determine this by looking at the form and surrounding content.

All form controls, such as text inputs, check boxes, select lists, or buttons, must each have a unique label. The label can be either a default value of the control, such as a submit button, or a correctly associated property or element, such as a label. While placeholders may provide additional hints, they are temporary and must not substitute a label. Labels must be visible and available to assistive technology.

Gesture based input, such as a slider or swipe-able select list, should also be clearly indicated. Any gestures must be implemented along with support for accessible alternatives, for example mobile keyboards.

iOS

When creating forms, make sure that the correct widget type for each input format is used. For example, use UIDatePicker to elicit a date from the user. Use a text field (UITextField) to elicit plain text from a user. Use UISwitch)to allow users to select between two possible values (such as on an off). The required semantics, behaviour, and gestures are built in to these widgets by default.

Native widgets can be further customised using a variety of associated properties. For example, the keyboardType property can be applied to UITextField instances to indicate the type of keyboard that will be presented to the user (text, numeric, etc.) when they encounter the text field. Examples include:

  • default - the default keyboard
  • decimalPad - for eliciting numbers, including decimals
  • url - for eliciting URLs

A typical example in Swift is provided as example code

When developing custom components that may have custom gestures, make sure that gestures are clearly indicated, either by way of a hint (through the accessibilityHint property) or, preferably, through the accessibilityLabel property to ensure that all VoiceOver users (even those who have hints disabled) are made aware of the gesture. For complex widgets, accessible alternatives may need to be provided if the interaction relies on a particular sense, such as visual or motor abilities.

iOS Example (Objective-C)

Example 1

Set the default input type for a text field

textField.keyboardType = UIKeyboardTypeNumbersAndPunctuation;

Example 2

Allow and indicate direct interaction for gestures

[aButton setTitle:NSLocalizedString(@"Smile", @"Button title") forState:UIControlStateNormal];

[aButton setAccessibilityHint:NSLocalizedString(@"Draw a smile on this button!", @"Accessibility hint for the smile button")];

[aButton setAccessibilityTraits:UIAccessibilityTraitSelected | UIAccessibilityTraitImage | UIAccessibilityTraitAllowsDirectInteraction];

Android

Apply the the android:inputType attribute to the editText element to select the type of keyboard that will be presented to the user when they interact with a form control. Examples of input types include phone pads, passwords, numeric text, and a variety of others.

Assist users by auto-correcting input errors through textAutoCorrect, and provide auto-complete suggestions through an AutoCompleteTextView. See example code.

Make sure that the correct input type for each form control is provided. Use an android:inputType of phone when eliciting phone numbers, use a DatePickerDialog for eliciting dates, the RadioButton object for radio buttons and so on. For custom components that require special instructions or gestures, make sure this information is included within the contentDescription.

Android Pass Example

Example 1

Setting the default keyboard type

<EditText android:inputType="number" ... />

Example 2

Using android:contentDescription to indicate gestures that can be used with graphical elements

<View android:contentDescription="Mood - Draw a smile or a frown" />

HTML

HTML5 introduced a host of new input types for forms, where developers previously had to create custom components. Examples include:

  • input type="search"
  • input type="email"
  • input type="tel"
  • input type="range"
  • input type="time"
  • input type="date"

Be aware, however, that support for these input types, particularly amongst legacy browsers and assistive technologies, is variable, hence (if support for legacy browsers is an issue) provide a fall-back approach for cases in which these input types are not supported (such as a custom date picker). In such cases, make sure that the fall-back widget is accessible. Custom widgets are discussed in a separate guideline.

Even when using one of the above input types, indicate any required formats textually within the form control鈥檚 label. For example, when eliciting a date, indicate the date format within the label. This will assist those users who prefer to add dates manually than choosing the date from the date picker widget.

HTML Pass Example

input[type=range] with descriptive fallback text in associated label:

<label for="t1">Rating (between 1 and 5):</label>
<input type="range" min="1" max="5" value="3" id="t1">                        >

Testing

Procedures

Activate a screen reader.

  1. Locate form fields.
  2. Verify that the keyboard type is relevant to the input, for example:
    • Text keyboard type is used for free text.
    • Number keyboard type is used for numerical input.
    • The phone number keyboard type is used for phone numbers.
    • The date keyboard type is used for dates.
    • The date and time keyboard type is used for date and time.
    • The month keyboard type is used for months.
    • The search keyboard type is used for search input.
    • The URL keyboard type is used for search.
    • The email keyboard type is used for email.
    • The password input type is used for password.

Refer to the following articles that demonstrate the different keyboard and input methods:

Apple:

Android:

Note: Be aware that, for HTML, older devices may not support all of the above input types, and will default to a simple text input. Hence, conduct testing using the browser on the latest operating system. If this is not possible, manually inspect the field using an inspection tool such as Firefox DevTools to check whether or not the correct input type has been applied.

Outcome

The following checks are true:

The correct keyboard type is presented to the user:

  • Text keyboard type is used for free text.
  • Number keyboard type is used for numerical input.
  • The phone number keyboard type is used for phone numbers.
  • The date keyboard type is used for dates.
  • The date and time keyboard type is used for date and time.
  • The month keyboard type is used for months.
  • The search keyboard type is used for search input.
  • The URL keyboard type is used for search.
  • The email keyboard type is used for email.
  • The password input type is used for password.