Mobile Accessibility Guidelines - Forms

Labelling form controls must

All form controls must be labelled.

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. For example, when requiring a user’s email address, “Enter your email address” could be used as the permanently visible label, and “email address” as the placeholder text.

iOS

Take the following steps to labelling form controls on iOS:

  1. Use a UILabel to provide a visible text label for each form control.
  2. Optionally, remove the visible text label from VoiceOver swipe focus order by applying the isAccessibilityElement property to the UILabel text, and setting it to a value of false. This approach prevents the label text from being conveyed twice when navigating through the page (i.e. this ensures the label will only be announced when the related form control receives focus).
  3. Make sure that the appropriate trait (for example, UITextField) is used for each form control.
  4. Make sure that the form control is appropriately labelled via the Identity Inspector, and is accessibility enabled. Alternatively, apply the accessibilityLabel property at code level to provide a label. In most cases, the label text should match the visible label text set via the UILabel class.
  5. If the form field is required, ensure this information is included within the accessibilityLabel.

Optionally, add a hint to provide additional instructions or explanation for screen reader users. Be aware, however, that VoiceOver users can choose whether or not to hear hints on their device so, while hints are turned on by default, the text might not necessarily be conveyed. Therefore, a more robust method is to include the additional text within the form control’s label, either in the Identity Inspector or via the accessibilityLabel property.

iOS Example (Objective-C)

[myLabel.setIsAccessibilityElement:YES];

[myTextField.setAccessibilityLabel:@"Your first name:"];

[myTextField.setAccessibilityHint:@"Entry must be between 4 and 20 characters."];

iOS lacks a specific required attribute or property. The generally accepted approach is to use an asterisk character to indicate required fields, but VoiceOver will normally announce this character as “star” or “asterisk” rather than “required”.

To resolve this issue, include the asterisk within the (visible) label, and then use the accessibilityLabel property to indicate that the field is required.

self.myTextField.accessibilityLabel = “First name (required):”;

Android

For basic form controls, use the android:labelFor attribute to provide labels. See example 1.

There is no specific required attribute or property when developing native Android applications. However, required fields can be indicated by overriding the label text using the contentDescription property. The content of this property will then be read out in place of the label text by TalkBack. In the following example, TalkBack will announce Edit box for ‘First name (required)’ when the field receives focus. See example 2.

Android Pass Example

Example 1:

<TextView
  android.layout_width="wrap_content"
  android.layout_height="wrap_content"
  android:text="Your first name:"
  android:labelFor="@+id/firstname" />
<EditText
android:id="@+id/firstname"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:inputType="text"/>

Example 2:

<TextView
  android.layout_width="wrap_content"
  android.layout_height="wrap_content"
  android:text="First name:*"
  android:labelFor="@+id/firstname"
  android:contentDescription="First name (required)"/>
<EditText
  android:id="@+id/firstname"
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:inputType="text"/>

HTML

Use the label element to explicitly associate form controls with a visible label. Apply the for attribute to the label. The value of this attribute must match the ‘id’ attribute of the related form control. See example 1.

In some cases, the visual design of the page may mean it is difficult or potentially confusing to display a separate, visible, and programmatically associated label. Examples include form controls inside data tables (whereby non-associated table headers represent visible labels) and search fields (whereby a button visibly labelled Search, or a magnifying glass icon, may already indicate it’s a search field). In such cases, the title attribute may be used. See example 2.

Use the aria-required attribute to indicate required form fields, as well as a visible indication (such as an asterisk). This ensures that assistive technology users are informed that the field is required. If support legacy browsers is not an issue, use the HTML5 required attribute instead.

If an ASCII-based asterisk is used to indicate a required field, ensure this is hidden from screen readers by applying the aria-hidden attribute to a container for the character, and set its value to false. See example 3.

HTML Pass Example

Example 1

  <label for="firstname">First name (required):</label>
  
  <input type="text" id="firstname">

Example 2

  <input type="text" title="Enter a list of search terms">
  
  <input type="button" value="Search">

Example 3

  <label for="firstname">First name:<span aria-hidden="true">\*</span></label>
  
  <input type="text" id="firstname" aria-required="true">

Testing

Procedures

  1. Activate a screen reader.
  2. Navigate through form fields on the page.

Outcome

All checks are true:

  • Visual labels are present for all form fields.
  • A screen reader announces all form field labels correctly.
  • Verify that the label, when taken out of context, clearly and uniquely describes the purpose of the control and the action the user must take.
  • Constraints of the field are announced properly via a screen reader.
  • Required fields are clearly indicated by a screen reader.