Skip main navigation

How to Address Typical Accessibility Issues in Web Forms

This article provides a ‘before-and-after’ example that illustrates some typical accessibility issues in web forms and how they can be addressed.
Typical accessibility issues in web forms include adding required or obligatory input fields, labels for input fields, grouping of form controls for easier navigation and understanding, as well as error prevention.

Before we show you the differences, try the Before version of the form with a screen reader such as NVDA or VoiceOver, then try the After version of the form. Don’t forget to use your keyboard rather than the mouse to go through the forms.
Then listen to the ‘Before’ and ‘After’ examples by going to the voice-over outputs link beneath each of the images below. You may find it helps to close your eyes whilst you listen. What do you notice? Did you have the same experience when you tested the forms?


inaccessible web page form
Voice-over output for ‘Before’ example in Read/Browse mode
This is what the VoiceOver screen reader says as the user tabs through the first version of the form – ‘Before’ example.
  • Registration page HTML content
  • Heading level 1 registration form
  • Required information is marked in red
  • Heading level 2 personal information
  • First name first name edit text
  • Last name last name edit text
  • Date of birth date of birth edit text
  • Email edit text blank
  • Selected radio button male
  • Radio button female
  • Enter the code in the image enter the code in the image edit text
  • New button
  • Submit button


Accessible webpage form
Voice-over output for the After example in Read/Browse mode
This is what the VoiceOver screen reader says as the user tabs through the second version of the form – ‘After’ example.
  • Registration page HTML content
  • Heading level 1 registration form
  • Required information is marked in red and with star
  • Heading level 2 personal information
  • First name first name edit text
  • Last name last name edit text
  • Date of birth date of birth edit text
  • Star email edit text blank
  • Gender
  • Gender selected radio button male
  • Gender radio button female
  • Submit button

How the main barriers are addressed in the ‘After’ example:

1. Required fields

In the ‘Before’ example, the colour red is used to show the required fields in the form. Using colour as the sole method to provide necessary information is problematic for blind and colour-blind people. An alternative other than colour should be provided. In the ‘after’ example, a ‘*’ is put in front of the label for the required field. It is also recommended that required fields should have the ‘required’ attribute. For example,
 <input type="text" name="email" id="email" required>

2. Label for input fields

In the ‘Before’ example, the form controls (text input fields, radio buttons, checkboxes) are not explicitly associated with their (corresponding) labels. They are only ‘visually associated’, i.e. through their positioning next to the fields). For example, the input field description ‘First name’ refers only visually to the input field.
When users move through form controls using the Tab key, screen readers usually do not read the surrounding text, which are the visual labels in the example. In order for the user to know what inputs are expected, it is necessary to associate the labels with their form controls. This can be achieved by using the ‘for’ attribute for the label.
Instead of
First name:<input type="text" name="firstname" id="first name">
It should be
<label for="first name">First name:</label>
<input type="text" name="firstname" id="first name">
The value of the ‘for’ attribute in the label should be the same as the value of the ‘id’ attribute in the control element.

3. Grouping of form controls

The combination of <fieldset> and <legend> is useful to provide a high-level description for a thematically related set of controls and labels. It not only makes it easier for users to understand the purpose of the group controls, but also provide support for keyboard navigation and screen readers. In the ‘after’ example, the male and female radio buttons are grouped together.
Note that the legend should not be too long because screen readers speak both the legend and the label for each of the input elements in the fieldset element.
<fieldset><legend>Gender</legend><input type="radio" name="gender" id="male" value="male" checked><label for="male">Male</label><br/><input type="radio" name="gender" id="female" value="female"><label for="female">Female</label><br/>

4. Instructions for form controls

It is often useful to add instructions for form controls, to specify what input is expected and in what format. The instructions are important for error prevention and particularly helpful for users with cognitive disabilities.
In many simple cases, providing instruction within the label is sufficient. For example, in the ‘After’ example,
<label for= date-of-birth>Date of birth (dd/mm/yyyy):</label>
<input type="text" name=" date-of-birth" id=" date-of-birth">
The input format for the ‘Date of birth’ control is specified in its label with “(dd/mm/yyyy)”.
These are called in-line instructions. Sometimes it is necessary to provide instructions outside the label, which allows more flexible positioning and design. This can be implemented by using WAI-ARIA tags such as aria-labelledby, aria-describedby.
In addition to instructions within and outside labels, it is also good practice to provide overall instructions that apply to the entire form before the <form> element.

5. Using CAPTCHA

In the ‘Before’ example, a CAPTCHA is used to differentiate computer programs from human beings, so that the server does not process the input by computer programs.
As you have heard from the voice-over or read the transcription for the ‘Before’ example, the CAPTCHA is completely ignored by the screen reader and is therefore invisible to those who cannot see it and depend on speech output.
In addition, the letters in the CAPTCHA are red and have very poor colour contrast. These create barriers for people with colour-blindness or low-vision.
More information about CAPTCHA accessibility issues.
In the ‘After’ example, the Honeypot technique is used to replace the CAPTCHA. A hidden field is added to the form. It is invisible, so users will not fill anything in the field. But a computer program will be able to see the field and fill it. By checking whether the field is empty or not, the server is able to identify input from computer programs.
<input id="test_name" type="text" name="name" value="" />
#test_name {
display: none;

© This work is a derivative of a work created by Høgskolen i Oslo og Akershus, and licensed under CC-BY BY 4.0 International Licence adapted and used by the University of Southampton. Erasmus + MOOCs for Accessibility Partnership.
This article is from the free online

Digital Accessibility: Enabling Participation in the Information Society

Created by
FutureLearn - Learning For Life

Our purpose is to transform access to education.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.

Learn more about how FutureLearn is transforming access to education

  • 30% off Futurelearn Unlimited!