Hyperlinks and forms are the most commonly found interactive elements on the web page. Providing accessibility features for forms is the most easiest but commonly ignored part while developing a website. Commonly observe forms on website are contact form, purchase form, sign up form etc. In this article let us understand the step by step. procedure to develop an accessible form. In the next article we will discuss how to make the validation and error handling accessible.
- Step 1: Using native HTML form elements.
- Step 2: Providing accessible label.
- Step 3: Associating the labels with the form elements.
- Step 4: Providing Descriptive labels.
- Step 5: Grouping related form elements.
- Step 6: Providing additional instructions for form elements.
- Step 7: Informing the state of form elements.
- Step 8: Keyboard accessibility for form elements.
- Step 9: Providing the logical order for form elements.
- Step 10: Keyboard focus visibility.
- Step 11: Change on input or on focus.
- Step 12: Use of ARIA.
Step 1: Using native HTML form elements.
To develop a web form one should know the native HTML tags and attributes used to create that particular element. Eg: use of input tag, the attributes used to define the text field, checkbox, radio button, combo box etc. In certain cases instead of a native element a custom control is used. We will understand what a custom control and how to identify in a while.
The following element is a native HTML text field.
The following is a native HTML radio button.
The following is a native HTML checkbox.
All the above elements can be made available using an image as shown below.
For the native elements when the user navigates the assistive technology accurately announces the type and state of the form elements. Eg: A radio button announces radio button not checked and check box announces checkbox not checked. In case of custom control it will neither announce the type nor the state unless the author makes the required coding.
WCAG 2.0 Check-point
4.1.2 Name, Role, Value (Future link)
Step 2: Providing accessible label
In step one we have just defined the form element. For the user to identify the action associated with it or to enter some information, select an option a label or accessible name is required. The label should be provided for form element using the label tag. Except for a button all other form elements support label tag.
The following text field has a label First Name.
The following check box has a label “I accept the terms & conditionsâ€.
Note: All the form elements have the label before the form element accept for radio buttons and checkboxes.
Providing label for a form button
When a native form button is developed provide a value attribute that describes the action associated with it.
The following form element is a login button.
When a visible label cannot be provided for a form element a “â€title†attribute or aria-label can serve the purpose of label.
WCAG 2.0 Check-point
3.3.2 Labels or instructions (Future Link)
Step 3: Associating the labels with form elements
Once the label is provided it should be associated with it’s form field. The association can be made using the “forâ€and “id â€attributes.
For the following text field the first name label is associated.
The following check box has a label “I accept the terms & conditions†and is properly associated with for and id attributes.
In case of title and aria-label they will be associated by default.
WCAG 2.0 Check-point
1.3.1 Info and relationship (Future link)
Step 4: Providing descriptive labels
The labels provided for the form fields should be descriptive. Users should be able to clearly identify the text that has to be input in the text field, should be able to identify the purpose of a dropdown, should be able to identify the action associated with a button etc. If the same label should be provided in two different places of the page ensure that the user is able to clearly differentiate them.
For example on a page if Father’s name and Mother’s name should be provided, mention them as “Father’s nameâ€and “Mother’s Name separately instead of mentioning the label as Name twice in the same page.
WCAG 2.0 Check-point
Step 5: Grouping related form elements
When a set of elements form a group user should be intimated that these elements belong to a group. For example Parrot, peacock, dove, crow belong to a group called birds. Tiger, lion, elephant, dog belong to a group called animals. To group similar elements like this a fieldset and legend tags are used. A fieldset will group the elements and the legend provides a label for the group. Below is an example to explain the same.
WCAG 2.0 Check-point
1.3.1 Info and Relationship (Future link)
Step 6: Providing additional instructions for form elements
Certain form elements need additional instructions to fill the element. For example the format of the date to be entered, password criteria, user id criteria etc. Providing instructions should allow the user to minimize making mistakes. The instructions should be placed before the field, incase if the instruction is after the field content authors should programmatically relate the instruction with the field allowing the assistive technologies to announce when user focus on the field. The programmatic relation can be provided using techniques like aria-describedby. Below is a simple date field example.
MM/DD/YYYYformat
Below is an example using aria-describedby
MM/DD/YYYYformat
Take care that the instructions are not based on sensory characteristics such as shape, size, visual location, orientation, sound or color.
WCAG 2.0 Check-point
3.3.2 labels or instructions (Future link)
>Step 7: Informing the state of form elements.
The native HTML elements have the capability of announcing the state of radio buttons or checkboxes without any additional effort from authors. However in certain cases where the form element is in disabled state or in readonly state etc content authors should ensure that the state of the field is properly conveyed to the users of assistive technology. Using attributes such as disabled=”disabled”, readonly=”readonly” screen readers will identify the state. Aria-disabled=”true” and aria-readonly=”true” can also serve the same purpose .
The below text field is readonly.
WCAG 2.0 Check-point
4.1.2 Name, Role, Value (Future link)
Step 8: Keyboard accessibility for form elements.
All the form elements should be navigable and actionable using a keyboard. If a radio button cannot be selected by a keyboard or a selection cannot be made from a dropdown or a form cannot be submitted using a keyboard alone certain user groups will not be able to use the form. If a login button can only be activated by a mouse, screen reader and keyboard only users never can log into the portal.
The following is a login button which cannot be activated with a keyboard.
WCAG 2.0 Check-point
Step 9: Providing the logical order for form elements.
The tabbing order of form elements should be logical and intuit. A sequential order should be maintained wile the user tabs through the form. In the below example while tabbing user will be navigated from First name to Gender before navigating to last name and then to the age fields.
WCAG 2.0 Check-point
Step 10: Keyboard focus visibility.
Take care that the keyboard indicator is visible on the form fields when they are focused. This wil enable the low vision users to keep track of the elements they are navigating. In some cases the default focus indicator is not sufficient to allow the users to identify the focus of form fields. In such scenarios authors should be able to provide author defined CSS with more contrasting colors. Below is one such example style.
WCAG 2.0 Check-point
Step 11: Change on input
Making a selection from the user interphase element will some time cause the change of context without the intimation to the user prior to the change. For example, When the user selects a language from the language dropdown automatically the language of the page changes without allowing the user to confirm the change. Ensure that the change occurs to the page only when the user selects or input something and confirms the change. Providing a confirm button or a go button allowing the user to confirm the change is vital.
WCAG 2.0 Check-point
3.2.2 On input (Future Link)
Step 12: Use of ARIA.
ARIA can be extensively used to Make a form accessible. In the below example the login button shown above will be made accessible using ARIA.
In the above example, alt provides the accessible label, aria-role allows the user to identify it as a button, and tabindex will allow the keyboard to navigate to it.
Following are few aria roles, states and properties used to develop an accessible form.
- Button role
- Checkbox role
- Combobox role
- Form role
- Option role
- Radio role
- Radiogroup role
- Spinbutton role
- Textbox role
- aria-autocomplete property
- aria-checked state
- aria-describedby property
- aria-disabled state
- aria-invalid state
- aria-label property
- aria-labelledby property (future link)
- aria-multiline property (Future link)
- aria-pressed state (Future Link)
- aria-readonly property (future link)
- aria-required property (Future link)