A laptop screen is open to a page with a form asking the user to "Fill out your pickup information."

Making Website Forms More Accessible

When it comes to making website forms accessible, there’s one basic thing to remember: Forms should have clear instructions that are available to all users.

You may wish to put overall instructions before the form begins. For example, “All fields are required.” There is a risk that screen reader users may jump directly into the form fields and miss this text, however.

How Do You Add Form Instructions?

Form label

The simplest way to add form instructions is to include them in the form label. This form asks for the user’s date of birth and tells them that it should be in mm/dd/yyyy format. In addition, this field uses an input mask to visually indicate the required format. This only permits numeric input in the format specified.

Placeholders

What about using placeholders? You can use them in addition to labels to indicate the type of input you want, but be aware that there are a number of accessibility issues with them. The first is that placeholder text disappears when a user starts typing, so your users might forget what they have to enter. Another issue with placeholders is that some users may think they have already filled in a field if they see placeholder text there. Also, placeholders usually don’t meet the minimum color contrast needed for accessibility, nor are they translated automatically by browsers. And finally, not all assistive technologies read out placeholders.

ARIA

A better option for providing instructions is to show instructions visually, often below the form field, and use the aria-describedby attribute to programatically associate the instructions with a field. In this example, the hint for creating a password is read out by the NVDA screen reader as “Choose a password  edit  protected  The password must contain at least 12 characters and include at least one number and one special character.  blank”.

If you simply put the instructions in a <p> or <span> tag near the form field without this association, the information won’t be available to screen reader users. 

Examples

In this registration form, the hints for creating a password are not associated with the password field, so a screen reader user will only find out the password format if they enter it incorrectly.

HP’s “Create an account form” tells screen reader users that their email address will be used as their username, but fails to let them know all the requirements for password creation. These are only given to sighted users when the password field is focused.

It’s a shame because the form does show sighted users when they meet the password requirements.

Humanware’s “Create an account form” gets it right: it does read out the password hints to screen reader users.

You can also use aria-describedby to programatically associate instructions with a group; it’s best to associate them with the first item in the group. Here this is done with a <fieldset> and <legend> grouping for radio buttons.

And here is the same for checkboxes. However, when testing with NVDA on Windows, the screen reader reads out the description for the list of radio buttons but not the checkboxes. This is actually a known bug with NVDA.

In this case, since the instructions are not too verbose, you could add them to the <legend> to be sure that they are read out. They are read as “Desserts (choose up to 3)  grouping  check box  not checked”.

If you have multiple sets of instructions relating to a single form control, you can use aria-describedby to label them. You do this by adding the ids of the descriptions to the aria-describedby attribute, like so. A screen reader will read the instructions out in order of the ids.

WordPress users can use the Gravity Forms plugin to add aria-describedby text. By filling in the Description field in the form settings, it creates a description field which is linked to the form input. 

The WPForms WordPress plugin also has a Description feature for form fields, which is read out by a screen reader like NVDA. Note that for grouped items like checkboxes, the description is read out multiple times.

The Wimbledon online shop does have some accessibility issues with its checkout form:

  • The font size of the labels is quite small and some of the text is too pale to read easily.
  • The text below the email address field “Join MyWimbledon to ensure you can see live details of your orders progress and receive new product news and offers first.” is only in a <span> tag without an aria-describedby, so it isn’t announced to a screen reader user.
  • A couple of fields (email address and mobile number) have clickable tooltips, but the text of these is also not available to screen reader users. They are told there’s a tooltip if it’s expanded, but they don’t get the tooltip text read out.
  • The delivery section is problematic too as it’s formatted in a table. Tables in forms aren’t recommended if they are for layout only. 
  • A screen reader user isn’t told about the free delivery for purchases over £100, and for the standard and express delivery options, they’re not notified of the prices or the delivery times. 
  • And confusingly, users are warned to select the right country if overseas, although the only option in the select element is the United Kingdom!

By contrast, the “Create an account form” from Timberland UK has some good accessibility features for screen reader users. The hint for the format of the date of birth is read out, and the extra information indicated by the i signs is indicated to a user and read out if they press “Enter.” The password hints are also read out and the asterisks indicating required fields are not announced. Instead the required fields are indicated with the required html attribute. It would be nice if the links to the terms and conditions and privacy policy indicated that they open in new tabs.

Learn more about designing accessible forms and other types of content here.