This article outlines some of the ways you can make sure your address forms are accessible and easy to use.
Most websites use a variety of forms that allow users to log in or reset their password, sign up to a newsletter or contact a company.
Other web forms, like those for buying products and services, can contain more complex fields. Like address lookups. The article covers general accessibility best practice for web forms, with a section on address lookup API tools towards the end of the article.
Follow this best practice advice to make sure all website visitors can use your web forms.
Written by Tim Webster, senior software engineer at Inviqa.
Give clear instructions
It’s easy to assume that all your users will know how to complete a form. But this is an assumption you cannot afford to make. Always assume your users do not know how to fill out a form.
- give clear instructions about the purpose of the form
- make sure labels are accurate and informative
- make sure these labels are in the correct field
If a user is confident in completing the form, additional instructions and labels will not bother them. But for users that rely on technology like screen readers, not having clear instructions can make them impossible to use.
Even the most simple form benefits from having clear instructions. Take this password reset form, for example.
Most users will find this form simple and easy to use. But it could easily be improved by adding some more instructions and information.
A simple introduction to the form tells the user what’s expected and what will happen when the form is submitted. Even having “Email address” as the form label is better than just “Email”.
A sighted user can see that the form field is required by the use of an asterisk, which is common in today’s web forms. But for screen reader users it’s better to be more explicit by using the aria-required attribute on the input field.
Always use labels
Screen readers rely on labels being associated to their form fields using ‘for’ and ‘id’ on the respective elements. This means that as the user navigates the form, the label of each field is announced when the field comes into focus.
It’s important to group elements together such as radio buttons or checkboxes and use fieldset and legend where appropriate to label the grouping as well as the individual items within the group.
Placeholder text is an easy way to give an example of what’s expected of the user. But it should never be used to replace form labels.
An example of this would be when asking the user to fill information in about their gender. When navigating through the form, if the first item read out to the user is “male” the user has to guess what the question is.
Grouping the fields with an appropriate label such as “Please enter your gender” gives the user more information about what is needed.
Check colour contrast
As with all elements of an accessible website, WCAG 2.1 level AA requires a colour contrast of at least 4.5:1 for standard size text and 3:1 for large text.
For other elements like graphics or icons, the minimum contrast ratio is 3:1. How to understand WCAG colour contrast ratio requirements and AAA levels.
You should follow these colour contrast requirements for all elements that make up your web form. Including:
- headings
- labels
- input field borders
- form instructions
Take extra care with your success and error messages too. It’s easy to forget these when checking your colour contrast. The green and red colours commonly associated with these messages often do not meet the minimum colour contrast requirements.
Check the contrast ratio between text and background colours using the WebAIM colour contrast checker.
Tell users about errors
Inevitably some users will make mistakes when completing your forms. This is why telling the user about which fields have been completed incorrectly is important. This is often done by highlighting the field or label in red.
But to improve accessibility, it’s better to go one step further than just telling the user which fields are incorrect.
Adding a message explaining how the user can correct the error, such as “The postcode you have entered is incorrect, please enter a valid postcode”, is far more useful than highlighting alone.
Never rely on colour alone to convey meaning. This excludes those with low vision and colour vision deficiencies (colour blindness).
Make sure it’s keyboard accessible
Many users will be navigating your website without a mouse. For example, people with motor or dexterity impairments. Or people using assistive technology. These users will typically use the ‘tab’ key to navigate your website.
It’s important that your users can navigate forms using just the keyboard too. To make sure your form is keyboard accessible:
- follow a logical reading order
- avoid complex layouts that will shift the focus drastically between areas of the form.
- Use <buttons> for submitting the form rather than links or other html tags such as spans and divs that have been styled like buttons. Otherwise, people using assistive technology will not be able to focus on the correct element.
If you’re using JavaScript, be sure to replicate any mouse events to allow keyboard users to use all functionality within the form.
Using aria-live regions is a great way to make sure screen readers are aware of any content or information the user adds to the form as the user is completing it.
Address lookup tool accessibility
This article and screenshots specifically refer to the Loqate address validation tool. If you’re not familiar with Loqate, it’s an address lookup tool that you can use when building an address form. Address lookup API tools make it easier for users to fill out contact forms with their address details. There are many different free and paid alternatives to Loqate. Like Fetchify, AFD software and Ideal Postcodes.
How address API lookup tools work
When a user types their address, the Loqate API makes a real-time search and returns a list of possible addresses for the user to choose from. When the user selects an address from the list, the tool fills the remaining address fields with the information needed. Leaving the user to fill in just a few more fields, like their phone number, to complete the form.
Adding automated address search and verification to a form is a great way to improve the user experience. Searching for your address and selecting it from a list is much quicker and easier than entering it manually. For users with access needs, address lookup tools significantly reduce the time it takes to complete a form.
And it allows the website owner to check and verify the address before it’s submitted to the server. Reducing the risk of costly spelling mistakes and typos.
How to avoid clashes with browser autocomplete function
One issue you may experience when using an address API lookup service is that it can clash with the browser’s native autocomplete functionality.
Both the browser and Loqate offer a list of address options that the user can select from, which can be confusing and distracting. For keyboard users, this can be especially challenging.
As you can see in the example above, Loqate’s address list is placed below the browser’s address options. This makes it impossible to read the address options below it. And for users with assistive technology, selecting an address becomes near impossible.
To overcome this, pressing the down arrow would highlight the first option offered by the browser autocomplete. Pressing tab will then shift the focus to Loqate’s options, but this is neither user friendly nor intuitive.
It’s also possible to avoid this by disabling the browser’s autocomplete on the relevant fields. But this then removes functionality that some users might rely on. Again, this is not great for the user experience.
The solution
However, by making some small but important changes to the form you can use both. An example of this would be to add a search field to the form. This field would have the Loqate functionality attached to it, allowing users to use the address search if they wished.
Disabling autocomplete on this field is less damaging to the user experience as the user is unlikely to have addresses stored in their browser for a field with a name of “searchAddress” or some other field name not commonly found in an address form.
Giving the user a way to enter their address manually allows them to use the autocomplete option on input fields named “street” or “postcode”. You can see an example of this in the image below.
Now the user has the option to either search for their address or enter it manually. Now when searching, with autocomplete disabled on the search field, there is no longer a clash with the autocomplete options.
If the user wants to enter their address manually, they can still expand the form and use the autocomplete function as normal.
Checking screen reader accessibility
While this solves the problem of your web form and autocomplete clashing, there are a few other points to consider. For assistive technology users, you must make sure that when the address options appear, the user is aware of this and can navigate through the address options.
When using the NVDA screen reader and performing an address search, you’ll notice that despite the address options being displayed to the user, there is no audio cue to suggest that the address options are available or that the user can select them.
One way of making sure that these are announced to the users is by using an aria-live region and some JavaScript code. When Loqate returns the list of addresses for the user to choose from, by updating the contents of the live region, even if hidden from view, screen readers such as NVDA will tell the user that the address options are there.
This lets the user know that there’s a list of options they can navigate using the arrow keys. They can make a selection using the enter key or press escape to exit the list.
As the user scrolls through the list using the arrow keys, you are again able to update a second live region to announce to the user the contents of the current address option that they are focusing on.
If using more complex features such as Loqate’s country selector that allows the user to change which country they are searching in, you must make sure that these options are both reachable using keyboard alone. And that they follow the natural tab order in which they appear in the form.
Test your form
Take your time when creating forms, think about all the ways your users will interact with them. Test them using different assistive technologies. Ask a range of disabled people and listen to their feedback.
Ultimately the more accessible your form is, the larger the audience is that can use it.
Related services
To understand if your website or app is accessible, why not look at our accessibility audits? We can tell you how to improve the online experience of your disabled customers.
