.svg){kind=small}
Accessibility is a hot topic in the UX community. This article outlines what accessibility means in a form context, what the common issues are and tips to help you improve your form accessibility.
By form accessibility, we mean making your form easy to interact with and complete for all users including those with disabilities. Amongst other things this means making sure that:
Perhaps one of the biggest failed promises of the “online world” as we know it was that by its very nature it would provide access to information for everyone. In fact, its creator, Tim Berners-Lee recognised this problem long ago when he acknowledged that the accessible internet he envisioned in 1983 was falling short of the mark. This prompted him to establish the Web Accessibility Initiative (WAI) in 1997. It just had one aim, to make the web and its content accessible for everyone.
“The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect” - Tim Berners-Lee, 1997
WAI is responsible for developing what is widely seen as the international standard for creating content on the web that can be accessed by everyone. That means whatever content is served up works for all people no matter what their hardware, software, language, location or abilities (hearing, movement, sight, cognitive, neurological, speech) are. The WAI guidelines and standards help to ensure that websites, tools and technologies are designed and developed so that people with disabilities can not only use them, but perceive, understand, navigate and interact without barriers too. Side note: Accessibility also benefits people without disabilities, its whole mantra is about inclusivity.
It’s fair to say that accessibility is an underrated tool of optimisation and that it is a cataclysmic failure to do better on several fronts. Websites that are accessible offer greater advantages in many ways, not least the following:
However, the 2022 WebAIM Million Report that evaluated the homepages of the top 1,000,000 websites concluded that whilst a slither of improvement has been seen since 2019 when the first report was run, websites are still failing miserably even meeting the lowest level of accessibility conformance when benchmarked against the WAI Web Content Accessibility Guidelines (WCAG) for accessible content.
The utter shame of this is that 96.5% of all errors came from the above 6 categories and have done so for the past 4 years running.. Notice anything else? Here’s a clue, these 6 categories of errors are probably the most simple to fix, if only we could try a bit harder.
Whilst these types of errors are common across all elements that may make up an entire website, it’s important to point out that the constituent parts that are usually included in a form feature highly in the list for inaccessible content.
Missing form input labels weigh in at a whopping 46%. Empty buttons at 27%. Low contrast text, 83%. Add them together (as the usual components of a form) and you can start to gauge just how much of a problem inaccessible forms are. Then consider the fact that the humble form is going to be the primary mechanism for users to interact with you and your website in one way or another - whether it’s signing up for a newsletter, completing personal, delivery and payment information, carrying out a search or filtering for products - a form is the go to mechanism to do that.
As simple as this sounds, providing instructions that informs the user how to complete a form and use particular controls is crucial. And yes, this includes telling users what is mandatory or not and the type of data that is expected and the format to enter it in.
It’s crucial to remember that placeholder text is no substitute for a label and is often not widely supported by assistive technologies or older browsers.
Forms can be the most contentious part of a user journey for anyone, so it makes sense that when you ask for information it’s information that you actually need and the user is happy to hand over.
Tip: Do your own form audit and review what information requests are genuinely needed. Remove those that don’t need to be there and scrutinise those that are considered essential.
Overall, the order in which information is requested should be logical and make sense for the user (not you!). Similar themed information should be grouped together as it makes it easier for people to focus on one thing at a time rather than trying to assimilate a form in its entirety.
Grouping of information should not only be done visually, but also within the code that creates the form itself. For the latter this can be achieved using <fieldset> and <legend> elements or using WAI-ARIA to define a container element such as a DIV with a role=group and then using the aria-labelledby attribute to reference the ID of the text that serves as the label for that group.
By keeping a form’s layout logical both visually and by using the correct semantic markup behind the representative visual layer you will ensure that assistive technologies are able to correctly understand the hierarchy of information presented and therefore convey the page information correctly to the user. Semantic code will also reap you a suite of other benefits, such as code that is lighter (good for performance) and more easily maintained (saving resource time). Achieving good accessibility starts with the use of semantic code.
Labels should be used to identify all of your form controls, text fields, checkboxes, radio buttons, selects etc. Any label should describe a control’s purpose and the two should be associated either explicitly or implicitly. This ensures that any assistive technology can successfully understand the purpose of a form control and feed back to the user any given requirement being made.
To do this, the label must contain the for attribute which exactly matches the id of the form control. Eg.
<label for=”lastName”>Last Name:</label>
<input type=”text” name=”lastName” id=”lastName”>
If the ID of a form control isn’t known then you can use the label element as a container for both the label text and the form control. Eg.
<label>Last Name:
<input type=”text” name=”lastName”>
</label>
There are three primary ways to define a button. The most important thing to remember is to include the label!
Again, another heated discussion within optimisation, but for an accessible approach placing labels above the form field helps those with low vision and benefits those on mobile devices. But as the old saying goes, “it depends” on various other factors such as form field proximity and content.
Providing timely and informative validation within forms helps users avoid mistakes before trying to submit a form. Some of the key improvements you can make here include:
Required inputs should be suitably highlighted using labels and by adding the required attribute required aria-required="true” to the input definition.
Email, URL, number, range, date and time are all available input types within HTML5. By using them appropriately for the data type required, validation is assisted by providing specific controls appropriate for the situation. For example, input type=”date” may present a date picker.
Some types of data have a predictable pattern which means that regular expressions can be used to specify particular formats for a particular input and by doing so reduce error rates. Telephone numbers, post codes and serial numbers are good examples, just remember any localisation differences that need to be accounted for.
A user should always be given the opportunity to check any inputs and correct them if necessary, especially if the action that is about to be performed is permanent and the data can’t be checked on the fly. In addition, any irreversible action that can be performed by a user should request confirmation before being actioned and similarly a way to “undo” reversible actions should also be provided.
Providing user feedback is essential, not only to ensure good accessibility so those using assistive technology are made aware of a given situation, but in more general terms it will benefit anyone who is completing a task such as filling out a form.
By suppling suitable feedback and notifications as to whether an action that has just been performed has been successful or not, users are given the opportunity to fix errors as they occur should they need to, or to continue and progress with the task at hand with the confidence to keep going.
Feedback is usually served up in one of two flavours, overall feedback and inline feedback.
This sort of feedback should be provided when a whole task has been completed, ie. once a form has been submitted. It’s important to note here, that what you do not want to do is provide a raft of errors post-submit that could have been avoided whilst the user was completing the form. Overall feedback should be used when the user has completed the task successfully, or when an issue beyond the user's control has occurred that has prevented a form being submitted correctly. For the latter, instructions and help should always be provided to allow the user to return to the task to try again (if possible at the time) or an option to be notified to return to the task at a later time.
If you decide to use custom dialogue boxes to provide overall feedback, then they must match the functionality of a standard javascript alert box (keyboard navigation and respects users default settings for font size, colours and language).
A/B testing frequently shows that providing inline feedback that is in close proximity to a related input field, rather than showing a big list of problems grouped at the top of a page post-submit, reduces friction significantly on forms. You can use in-line validation in an accessible way by using a combination of messages and visual cues that clearly indicate the type of action required and clearly articulate what needs to be done to correct a mistake. This approach can usually be carried out whilst the user is typing into an input, or on focus change. The application of either approach is dependent on the type of data to be entered. For example, it may not make sense to check data as someone is typing (such as entering a date) because an error may be displayed prematurely - it would be better to wait until the input has lost focus and then present an error message.
Longer forms should be broken down into smaller logical steps or stages to increase understandability and reduce cognitive load. There are other elements that can help here too, such as:
The first page of your form should explain how many steps there are and provide feedback at each progression explain to the user where in the process they are. There are several ways to do this with accessibility in mind; Using the page title <title>, the main heading <h1>, the HTML5 progress element <progress> or an ordered list <ol><li>.
What is important for any of these approaches is that data is saved from one step to the next, users are able to navigate freely between each progression and that status of each step (completed or not) is clearly indicated visually and with text.
Some users visit your website and they won’t be using a mouse to navigate around. That’s why it’s really important that your form and all of its constituent components can be accessed via a keyboard alone. Evaluating the keyboard accessibility of a form (or go the whole hog and try it on your entire website, you may be horrified!) can be easily done. Take a look at this great cheatsheet by webAIM to get familiar with the standard keystrokes used for keyboard interactions and navigation.
Another thing to consider here is the focus order of the form, that means that when users encounter your form they are able to move sequentially through the content in a logical way with a keyboard. You can read more about this in the W3C WCAG 2.1 guideline Focus Order: Understanding SC 2.4.3
Time limits to complete a form are used in certain situations, most notably related to security measures. If a time limit is in place for this reason then the user should always be given the option to extend a time limit or to turn it off. There are some other situations too, such as forms that have a “time-sensitive” requirement, perhaps an auction or where the time to complete the form is essential for a valid submission. In these situations restrictions on using time limits are not applicable, but still need to be handled with care.
Form accessibility doesn’t need to be a difficult task, or defined as something that only benefits those who may be visiting your site via assistive technologies such as screen readers. There are many aspects of creating an accessible form that will provide benefits to your whole audience; the reward you get for putting in the effort to be inclusive will be substantial - whether that’s conversion rate, reducing friction and pain points or something else.
However, let's not lose sight of the elephant in the room. You may well plough your best endeavours, time and resources to ensure your forms are accessible, but it means little of nothing if the rest of your site accessibility fails at the first hurdle. If a user is unable to navigate to your form in the first instance due to lack lustre accessibility compliance elsewhere on your site, then you are by definition cutting your nose off to spite your face. Not only that, you’re barring access to your products and services to an audience who, if able to do so and given the chance to interact with you, may very well provide the answer to many of the metrics you wish to improve upon.
Zuko is the most powerful form analytics platform available on the market. Find out how to improve your form and checkout conversion by taking a product tour.
PRODUCT TOUR
