In this article we will be examining the fifth criterion under the Web Content Accessibility Guidelines “Adaptable” guideline.
You are likely familiar with the “type” attribute that many input fields support, for example <input type=”text” />. Common types include number, date, checkbox, etc. More niche types include email, tel and password. These are extremely useful, and often cue the browser to offer different behaviour for input. However, those types don’t provide much indication of the purpose of the information. For example, is the text a name? Whose email is it? Is the date a date of birth? Is the password the current password or the definition of a new one?
This success criterion requires us to provide an additional attribute for input fields which collect data about the user who is filling in the form so that the purpose of those fields can be programmatically determined, and useful behaviour can be offered to the user.
The autocomplete attribute
You might have used the autocomplete attribute in the past to set it to “off”, telling the browser not to offer autocomplete for specific fields (although note that most password managers will ignore this attribute). There are other possible values for this attribute, these are the ones we can use to identify the input’s purpose, for example:
- name – the user’s full name, or you could use the more granular honorific-prefix, given-name (i.e. forename), and family-name
- email – the user’s email address
- new-password / current-password
- address-line1/2/3, address-level1 (town), country, postal-code
- bday – the user’s date of birth
- tel – the user’s telephone number
And there are many more options, include a set for credit card and transaction details. You can view the full autocomplete attribute documentation to see them all.
Remember, these attributes should only be added to fields related to the user filling in the form, not any third party.
Benefits of using the autocomplete attribute
The obvious benefit is that browsers can offer more accurate options for autocompleting those fields. You may have noticed (particularly on mobile devices where autocomplete is more common) that forms on some sites seem to present better autocomplete possibilities than others. This may save time and frustration when filling in the forms. This may be of even greater importance to someone with a language or memory disability, or someone with a motor impairment.
There are some less obvious benefits too though:
- Some people may prefer images rather than text to communicate the purpose of a field. For example, people with a learning disability, cerebral palsy, stroke or motor neurone disease. They can use a tool to automatically add icons to fields based on their purpose.
- Some people may have problems easily understanding some of the text that websites use to label their fields. They can use a tool to swap out the labels for text they are more familiar with.
If you’d like to find out more, take a look at the following article: Understanding Success Criterion 1.3.5: Identify Input Purpose.
ARIA for the uninitiated
Last time we looked at the first article in a series published by accessibility specialists Deque, introducing the reader to the ARIA spec and how to use it well. The second article and third article are now available, looking at the ARIA authoring practices and an example of building an accessible control using ARIA.
Designing for accessibility
The Home Office has put together fundamental points to bear in mind when designing for users with particular needs. We continue our series with designing for users with low vision.
