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.

Examples

iOS

Key recommendations are:

  • Provide visual labels;
  • Use the accessibilityLabel property to name the form control;
  • Use the appropriate accessibilityTraits property to describe the type;
  • Use the accessibilityHint property when the form control needs instructions or explanation for screen reader users.

Android

Use editText to provide explicit labels for fields.

HTML

Key recommendations are:

  • Use explicitly associated labels;
  • Do not solely rely on ARIA labels;
  • Do not solely rely on HTML 5 attributes like title="".

Testing procedures

  1. Activate a screen reader.
  2. Locate form fields.
  3. Verify that all form fields have a visual label.
  4. Verify that all form field labels are announced by a screen reader upon navigation to the form field. Use tab or screen reader "next" control to navigate.

Testing results

The following checks are true:

  • Visual labels are present for all form fields;
  • A screen reader announces all form field labels.

Form inputs Must

A default input format must be indicated and supported.

All users benefit from clearly indicated, well supported, form input formats, whether text, numbers, date, or a specific combination. It makes it easier to get it right first time and reduces errors when completing forms.

The format required can be indicated as part of the label, set by correctly coding the input field, and assisted by providing the correct keyboard mode on devices that support it.

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.

Examples

iOS

UITextField elements use the UITextInputTraits protocol to control what type of keyboard will be shown to the user (numeric, text, etc.). Thus, the default type of keyboard can be set using the keyboardType property.

Accessibility traits can be used to provide special accessibility gestures such as flicking up and down to increase or decrease a value or using UIAccessibilityTraitAllowsDirectInteraction to allow users to use the control directly once it is focused. Accessibility Hints should be used to indicate special gestures.

Android

Use contentDescription to provide information on special gestures. The default keyboard can also be set using the android:inputType attribute of the editText element. This can be used to tailor the provided keyboard for entry of numbers, passwords or email addresses. See Android Developer Training - Keyboard Input.

HTML

In HTML 5 the type of input can be indicated by the type attribute. Examples include:

  • Date
  • Month
  • Number
  • Range
  • Tel
  • Text
  • Time
  • url
  • week

Without HTML 5 the input method can be indicated textually as part of the explicit label or through off-screen text for screen reader users.

Testing procedures

  1. Activate a screen reader.
  2. Locate form fields.
  3. Verify that form fields announce a input type or restrict the keyboard to relavant input.

Testing results

The following checks are true:

  • The input type is announced by a screen reader;
  • The input type is restricted via the keyboard.

Form layout Must

Labels must be placed close to the relevant form control, and laid out appropriately.

Labelling form controls helps users to understand what is required. Keep labels close to the associated form control to prevent users becoming disoriented, particularly users who magnify or zoom in on content.

Labels should precede associated controls, visually above or to the left of the input field. Labels for radio buttons and checkboxes visually work better to the right of the field, however, assistive technology such as screen readers must always speak the associated label before the input control. Labels for select lists may be included as the first item of the list itself.

Jump to:

Examples

Testing

Advanced

Examples

iOS

Provide visible labels that are visually close to the associated form field, for example, using the frame location and the textAlignment property. Ensure there is limited white space between labels and fields. Keep labels above form fields in portrait layouts. Labels may be positioned to the side of form fields in landscape layouts.

Android

Provide visible labels that are visually close to the associated form field, for example, using AutoLayout, the android:gravity or android:textAlignment attribute. Ensure there is limited white space between labels and fields. Keep labels above form fields in portrait layouts. Labels may be positioned to the side of form fields in landscape layouts.

HTML

Provide visible labels that are visually close to the associated form control. Use CSS media queries to remove empty space and position content into mobile friendly layouts. Also ensure that buttons in forms are not distanced from form elements.

Testing procedures

  1. Activate the app with zoom enabled to two times magnification.
  2. Gain focus on each individual form field.
  3. Verify that the control is visually labelled.
  4. Verify the label is in close proximity to the control.
  5. Verify that the label placement is most effective for the layout (portrait or landscape).
  6. Verify that the label of the field is announced properly by a screen reader and matches the label’s on-screen text.
  7. 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.
  8. Verify that any field constraints of the field are indicated in the accessible name announced by a screen reader.

Testing results

The following checks are true:

  • On-screen controls are visually labelled with meaningful names which when taken out of context describe the control’s purpose;
  • The label must be in close proximity to the field;
  • The label must be placed in an effective location for the layout of the screen:
    • Above the field for portrait
    • To the left of the field of landscap
  • The label of the field is rendered properly via a screen reader and matches the label’s on-screen text;
  • Field constraints of the field are announced properly via a screen reader.

Grouping form elements Must

Controls, labels, and other form elements must be properly grouped.

Properly grouped form elements help all users understand the relationships between form controls and make forms easier to use. For users of assistive technology this can mean fewer steps and reduced complexity.

Correctly grouped controls also ensure standard behaviours work as expected.

There are four things to consider when grouping form elements:

  • Correctly associating labels with form controls,
  • Correctly associating related radio buttons or checkboxes,
  • Wrapping related form elements in a labelled container such asfieldset with legend,
  • Keeping labels and legends succinct to minimise verbosity.

Jump to:

Examples

Testing

Advanced

Examples

iOS

iOS does not provide a mechanism for grouping controls. Controls that are related can be noted using the accessibilityLabel property to indicate the group that an object relates to, for example, to differentiate between a shipping and billing address field that would normally be labelled "Address:".

Android

Android does not provide any general method of grouping form controls apart from the RadioGroup structure. Radio buttons are normally used together in a RadioGroup . When several radio buttons live inside a radio group, checking one radio button unchecks all the others. Refer to Android Developer Training - organising content.

HTML

  • Ensure all radio buttons in a group have the same name attribute.
  • Use the legend and fieldset grouping to group form fields.
  • Use the ARIA radiogroup role when using non-standard HTML radio button controls.

Testing procedures

  1. Activate a screen reader.
  2. Locate any forms within the screen.
  3. Determine if one or more logical groupings exist within the form.
  4. For each grouping, navigate to each field in the group and verify that the group name is announced prior to the field’s label.
  5. Verify that the methods of interacting with each grouping work as expected with alternative input methods.

Testing results

The following checks are true:

  • On-screen fields that are part of a logical grouping have a visible group name indicated as part of the label for the on-screen field;
  • For each field that is part of the group, the group label is announced prior to the field’s label by either using platform conventions to associate fields with a group and testing using a screen reader, or pre-pending the group label to the accessible name of each field within the group;
  • For each group of items, navigation and interaction among the group items must work as expected for group items, for example, properly grouped HTML radio buttons allow navigation between them via up and down arrows.

Managing focus Must not

Focus or context must not automatically change during user input.

It can be disorienting and hinder users from verifying information or correcting mistakes if the focus automatically changes when the user is not expecting it. For example, moving to the next control or to a validation error message during input.

Focus must only change when activated by the user. This could be via mouse or touch, using 'tab' or 'flicking' to change form control, or using 'space' or 'enter' to activate a button.

Examples

iOS

Do not move focus between fields automatically. Require the user to select a new field manually to move focus.

Android

Remove focus shifts that the user does not control. For example, when a user selects a certain radio button via the keyboard, focus shall not move off of the radio button onto another component.

HTML

Keys points are:

  • Use the onBlur method rather than onChange method.
  • Do not move focus on input validation - for example, once a certain number of characters have been entered.

Testing procedures

  1. Activate the screen reader.
  2. Fill in form fields according to their constraints and verify that focus is not forcibly shifted when entering text, traversing a list or selecting an item.

Testing results

The following check is true:

  • Focus does not shift to other objects, elements, or controls while navigating lists, entering data into form fields or selecting an item within an object, element, or control.

Note: Focus movement to a sub-item of the object, control, element that is expected, such as movement to the next list item on using arrow key, tabbing or flicking, is desired and thus meets this check.