Accessibility Best Practices for Creating Form Designs
This is a series of four articles that discusses all aspects off creating accessible forms:
When we complete a task independently and successfully, the exhilaration is boundless. Filling forms on websites and apps for people with disabilities and even for the non-disabled is such a task and the independence in that is exciting, even if it is simple.
The other day, I was amazed when I encountered such a scenario on a travel site. Even though I am an assistive technology user with limited motor ability and limited cognitive ability, I was able to fill in all the details on that travel site within five minutes! And guess what? Without any error! You know how?
It was all because, the forms had descriptive labels that were visible at all times; marking of mandatory fields that was accessible to everyone; never-vanishing instructions that were easy to follow; grouping of relevant form fields that clearly defined the purpose of those fields; minimal use of placeholders that gave the necessary hints and above all, proper communication of the role, name and state of the form controls to the assistive technology that I was using. I know it sounds utopian. But in imagination, it is real.
In our last two posts, we saw the ill-effects of using the placeholder attribute & how to mark-up the required fields. If you have not taken a look at them then we recommend that you take a glance at these posts first & then come here.
- Anatomy of Accessible Forms! Placeholder is a Mirage
- Anatomy of Acccessible Forms! Required Form Fields
In today’s post we will go through all the ingredients of creating an accessible form that provides the best user experience for all the users. We will go through each aspect of creating an accessible form & understand why a particular step is important & how it affects people with disabilities or users in general.
Use Native HTML
The first rule to create a truly accessible form is to use native HTML form controls. They are accessible by default with all assistive technologies & it is semantically correct.
Let’s look at some examples of native form elements:
<input type=”text”>
<input type=”radio”>
<input type=”checkbox”>
<button>Submit</button>
Since we use the native HTML controls, the name, role & state of the elements are exposed by default to all assistive technologies. But if we are creating a custom control using WAI-ARIA techniques, all these need to be provided manually using various ARIA attributes like aria-label, aria-checked, role=”radio” etc.
Providing Visible Label
Now that we have talked about using the native HTML controls for the forms let’s dive into methods to make them accessible. The next step in the process is to provide visible labels for each form control. Without visible labels form controls are not usable to any user let alone a person with disability. A visible label is nothing but text that is in proximity to the form control that it is representing.
<b>First Name</b>
<input type=”text”>
<b>Terms & Conditions</b>
<input type=”checkbox”>
In the above example code, I have used bold tag to highlight the labels so that users can distinguish them easily. While we are at the subject of visible labels let’s recall a bit about placeholder attribute. For some of input types we can use placeholder attribute but it is not same as providing visible label. The placeholder disappears once user inputs data into form control & we discussed the pitfalls of placeholder in the post “Placeholder is a Mirage”. So provide visible labels for all the form controls that you create.
Programmatic Labels
Now that we have understood why we need visible labels & started to provide them, we need to associate them programmatically to their form controls. Without programmatic association of the labels assistive technology users cannot identify the purpose of the form field. When a user focus moves into a text field it is read out as “edit field” without notifying the accessible name provided to it. To make sure that the visible accessible name is notified to the users we need to associate the visible label with form field.
<label for=”firstname”>First Name</label>
<input type=”text” id=”firstname”>
<label for=”lastname”>Last Name</label>
<input type=”text” id=”lastname”>
In the above example, we have used for & id method to associate the form field with its visible label. There are multiple ways to achieve the association but using the for & id method is native and is recommended.
Providing Descriptive Labels
Now that we have provided visible labels & associated them with their respective form fields the next step is to check if the form labels are descriptive enough. Will the user be able to read through the label & can take a necessary successful action? For example
<label>Name</label>
<input type=”text”>
<input type=”text”>
In the above example we can see that for both form fields the visible label is name but is it descriptive enough for the users to take necessary action? Simple answer is no! We already discussed that each form fieldshould contain it’s own visible label & it should be descriptive enough. In the above example the fix would be to provide visible labels for both form fields & specify where first name & last name should be entered.
<label for=”fname”>First Name</label>
<input type=”text” id=”fname”>
<label for=”lname”>Last Name</label>
<input type=”text” id=”lname”>
Grouping of Form Controls
Sometimes there will be a set of form controls that belong to a group& is provided with a group level visible label. The group level label conveys the necessary information to the users to take action. Let’s see this with an example
<p>Do you have a passport</p>
<input type=”radio” id=”yes”>
<label for=”yes”>Yes</label>
<input type=”radio” id=”no”>
<label for=”no”>No</label>
In the above example we can see that “do you have a passport” is the primary visible label for the set of radio buttons. But when assistive technology users navigate to these radio buttons using the tab key they miss on the key information of the primary visible label as it doesn’t get tab focus & the elements Yes & No when read-out by assistive technology doesn’t make sense. To help with this problem in HTML we have fieldset & legend attributes that will help us bind the group level form controls which will be announced to assistive technology users as expected. Now we will see the same example with fieldset & legend
<fieldset>
<legend>Do you have a passport</legend>
<input type=”radio” id=”yes1”>
<label for=”yes1”>Yes</label>
<input type=radio” id=”no1”>
<label for=”no1”>No</label>
</fieldset>
In the above example we can see that fieldset is binding the form controls inside a group & the legend attribute is used as the primary label that will be exposed when assistive technology user moves the focus to the first radio button either in tab or shift+tab navigation.
Providing Instructions
Some of the form fields need additional instructions to fill the data successfully & these instructions must be available to the users at all times like visible labels. We can bind the instruction to the form fields using aaria-descrivbedby attribute.
<label for=”dob”>Date of Birth</label>
<input type=”text” aria-described=”dob1” id=”dob”>
<span id=”dob1”>Use DD/MM/YY</span>
In the above example, the instruction is provided below the form field & is bound using aria-describedby to the text field. If the instruction is not bound to form fields then assistive technology users who only use tab key might miss on the key information. By using arrow keys too, users can get all the information but it is a better user experience if the instructions are associated.
To conclude, following all the best practices discussed above will create a form that is usable & accessible by all users. Native HTML is the key to create this unique user experience! if you want to build a custom control from ground-up because something is not available in HTML then we recommend using ARIA roles, states & properties. We will be discussing about creating custom controls in our upcoming blog posts & we did not touch base on the subject of validating the form & error identification as it will be the next post in series.
