Zuko Blog

How to Improve your Online Form Accessibility

Techniques to improve usability and accessibility for all users, including those with disabilities

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.

What is 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:

The failed accessibility promise

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. 

What’s this got to do with optimisation?

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:

  1. Makes content, products or whatever it is you’re trying to sell or promote universally available to everyone who might be interested in it
  2. Opens up your market share to people who want to spend, but can’t because they can not access content. The 2019 Click-Away Pound survey puts this as an estimated 17.1 billion pounds in lost business. Can you honestly say you don’t want a slice of that pie? 
  3. Helps with SEO and site performance - Google is going to love you!
  4. Is a legal requirement in many countries - failure to comply can mean lawsuits. But don’t worry, you’ll be in good company.
  5. Inclusivity - can we truly say in 2022 this shouldn’t be a priority both morally and ethically?

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.

WCAG Failure Graph

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. 

  1. Low contrast text
  2. Missing alternative text
  3. Empty links
  4. Missing form labels
  5. Empty buttons
  6. Missing document language

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. 

How to ensure your forms are accessible

(i) Provide instructions

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.

  1. Provide instructions within labels. For simple stuff, just including the instruction within the label will work (eg. Date of birth (dd/mm/yyyy)). Reliable but might need some thought around styling.
Example of instructions within labels

  1. Provide instructions outside labels. If you need more flexibility this can work, but it relies on WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications, a technical specification used by developers to build interactive content that is accessible) which may not be supported by some assistive technologies (such as screen readers) and older browsers. aria-labelledby and aria-describedby can both be used.
  2. Placeholder text. This is information that is contained inside a form input but there are some common issues with doing this:

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.

(ii) Only ask what’s required

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. 

(iii) Keep it logical 

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.

(iv) Labelling

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.

  1. Explicit label association

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”>

  1. Implicit label association

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”>


  1. Buttons

There are three primary ways to define a button. The most important thing to remember is to include the label!

  1. <button type="submit">Submit</button>
  2. <input type="submit" value="Submit">
  3. <input type="image" src="searchbutton.png" alt="Search">

  1. Visual Positioning

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.

Accessible form field comparison
Which would you prefer?

(v) Validation

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:

  1. Providing clear indicators of required inputs

Required inputs should be suitably highlighted using labels and by adding the required attribute required aria-required="true” to the input definition.

  1. Validating common inputs

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.

Date Picker

  1. Patterned input

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.

  1. User validation

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.

(vi) User feedback

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. 

  1. Overall 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).

  1. Inline feedback

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.

(vii) Chunking

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:

  1. Repeating overall instructions for each page of your form
  2. Identify optional stages and provide the option to skip them
  3. Indicating progress

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.

John Lewis Step as Link
John Lewis provide each step as a link, as well as completed, currently active and next step indicators - nice!

(viii) Keyboard Accessible

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

(ix) Use time limits carefully

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.

In a nutshell

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. 

Additional Resources

  1. Siteimprove accessibility checker (chrome extension)
  2. Accessibility features in Chrome DevTools
  3. W3C accessibility standards overview
  4. Helpful WCAG guidelines when it comes to forms:

Looking to improve your form conversion?

Submit your form to get a free health check showing you:
  • Likely friction points leading to abandonment
  • Form elements contributing positively
  • Other areas for UX improvement
Zuko's Big Guide to Form Optimization and Analytics Cover Shot

We wrote the book on form optimization!

"The best book on form design ever written - 80 pages of PURE GOLD"
Craig Sullivan, CEO, Optimise or Die
(No email needed)

More from our blog:

Failed Form Submissions: Optimizing the Submit Button UX
Why failed submissions happen and how to reduce them
Optimizing the phone number field on forms
UX tips to reduce abandonment on mobile and landline form questions
Form UX Design Tips: Best Practice Examples
10 form design patterns that help optimize conversion
8 Tips to optimize your mobile form UX
CRO advice for forms on mobile devices

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.

zuko full colour logo
Formisimo Ltd, Colony, 5 Piccadilly Place, Manchester, M1 3BR
VAT Number: GB181252425
Registered in England as company number 08859680
New Business: sales@zuko.io
Support: support@zuko.io