We've created Zuko, our next-generation form analytics platform. Explore Zuko Explore Zuko > Hide Message

Building Accessible Forms 101


Today is Global Accessibility Awareness Day so let’s talk about creating accessible forms.

Accessibility is an effort to make web resources accessible to and usable by everyone, free from physical, cognitive or cultural restrictions. It’s not just about helping people with disabilities, web users with low vision, temporary mobility problems, short attention spans or decreased capacity for learning benefit from accessible web interfaces.

This is just a brief introduction to the kinds of accessibility issues forms can cause, how to address them and the added benefits to you.

Navigating around

Assistive technology, such as screen readers, are controlled by keyboard commands. Web users with mobility problems such as twitches in their limbs often find it easier to use their keyboard than their mouse to get around the page. In fact, plenty of web users find it easier to use keyboard commands.

To accommodate this you should mark up form fields in a logical sequence, allowing users to move to the next field using their keyboard. This is referred to as ‘setting the tabbing order’.

See W3C’s instructions on marking up links and form controls in a numbered tab index.

Example Code:
<form action="#" method="post">
 <table summary="the first column contains the search criteria 
  of the groom, the second column the search criteria of 
  of the bride">
 <caption>Search for marriage records</caption>
   <th>Search criteria</th>
  <th>First name</th>
  <td><input type="text" size="30" value="" name="groomfirst" 
      title="First name of the groom" tabindex="1"></td>
  <td><input type="text" size="30" value="" name="bridefirst" 
       title="First name of the bride" tabindex="4"></td>
  <th>Last name</th>
  <td><input type="text" size="30" value="" name="groomlast" 
      title="Last name of the groom" tabindex="2"></td>
  <td><input type="text" size="30" value="" name="bridelast" 
      title="Last name of the bride" tabindex="5"></td>
  <th>Place of birth</th>
  <td><input type="text" size="30" value="" name="groombirth" 
      title="Place of birth of the groom" tabindex="3"></td>
  <td><input type="text" size="30" value="" name="bridebirth" 
      title="Place of birth of the bride" tabindex="6"></td>

By adding tabindex = “1”, tabindex = “2” etc. to the each cell in the desired order keyboard users will be able to move between form fields using their tab key.

Controls and drop-down menus

Controls, such as buttons, radio buttons and checkboxes, and drop-down menus cause problems for several different groups:

  • Buttons and checkboxes only have a small clickable area which requires precision to focus on with a mouse. Make sure your labels are clickable too.
  • Options often lose their meaning out of context of the heading or label, meaning blind users might not understand the purpose of the list. Mark up labels so that they’re properly associated with their corresponding control or list.
  • Some client-side scripts cause drop-down options to be selected upon focus (as issue for keyboard users who have to move through a list). Avoid using these and instead only select if the user hits return.


Think about the context of your form. What do the labels and other explanatory text tell sighted users? Is it vital to understanding what to input in each field? Most likely it is. When a screenreader is in “forms” mode, it can skip content that would otherwise be read in browse mode, like explanatory text.

To ensure all the supporting information is available to all users there are two solutions:

  1. Put all the text inside the label element paired with the form element. (Tip by Greg Tarnoff, a developer and UX practitioner).
  2. Use the aria describedby attribute on the form element to point to the id of the explanatory text. (Tip from Curtis Wilcox, manager of the adaptive technology lab at Harvard). However, ARIA is not read by all screen readers.

Wilcox shared another tip for for “extra” text. “I like the option of adding tabindex=0 to the element so it’s in the tab order. For information that doesn’t need to be read every single time a form element has focus, it’s useful.”

Labels can also be used to expand the clickable area of a checkbox or to drop the cursor into a form field.

Fieldsets not divs

<div> elements are often used to style forms, grouping sections together. However, “<div> tags do not provide sufficient semantic information for assistive technologies to utilise.” In other words <div> is purely for styling and won’t tell a screenreader what that section in the form is for at all.

Follow Nomensa’s advice on form field grouping with fieldsets and legends.

Validation and error messaging

Form validation and delivering user-friendly, useful error messaging is very important for all users. Here’s a short guide to errors in forms and here’s a look at why errors happen.

If you found it hard to navigate the web page or couldn’t even see it imagine how much more difficult it would be to correct errors in a form. I ask the user experience design community for their advice on error handling in an accessible way.

WebAIM’s guide to Usable and Accessible Form Validation and Error Recovery was top of the list of go-to resources, followed by Web Usability’s Accessible Forms Using WCAG 2.0. (Both shared by @whitingx, UX designer and researcher).

Tarnoff (@gregtarnoff) shared his favourite example of delivering error messages in a more accessible way; error messaging next to the form field that also includes skip links to the next error.

A form with errors and skip links to the next error

Skip links save time for keyboard users

He also offered me this advice, “My recommendation is an error or hint placed in the <label> of that input. You can position them wherever you want, but then the AT [assistive technology] reads it and explains what to do before hitting the field.” This is great advice as it’s pre-empting errors occurring.

We both agreed that linking to vs. tabbing through the form to get to the next error is ‘super handy’.


I couldn’t end this post without mentioning CAPTCHAs. We’ve mentioned them on the blog before. CAPTCHAs are, by their nature, difficult to see. Anyone with low vision will struggle to differentiate the letters. Screen readers also struggle to read out the text because CAPTCHA are designed to deter robots, which screen readers essentially are.

An example of a CAPTCHA

CAPTCHAs are blurred and guard against machine reading

Although CAPTCHAs filter out spam you should be asking yourself what is more important? Dealing with spam or getting more conversions?

Find out more about the problems caused by CAPTCHA and the alternative solutions available.

Benefits to you

Developing your website and forms to be more accessible is not only the right thing to do but has many benefits for you too.

  • More people will be able to fill out your forms, increasing your conversion rate.
  • Accessible forms contribute to a better user experience for everyone because they’re easier to fill out.
  • Well coded forms can be picked up better by analytics scripts, such as those used by Formisimo.

What did you do to mark Global Accessibility Awareness Day? Developer Kate Busch-Petersen challenged us to ditch the mouse and try navigating a web page using only your keyboard.