How to improve the accessibility of web forms

Background

As part of my role at Nomensa I’ve spent a significant amount of time evaluating the accessibility conformance on a range of websites. When auditing these websites I have been consistently  surprised at the way in which web forms have been implemented. Forms can be a source of confusion for everyone, not least for people with cognitive disabilities and visual impairments. The information that follows should provide some guidance and advice on how to implement web forms in an accessible and user friendly way. If this guidance is taken into account at the design and implementation stages of a website build, your forms will be significantly more accessible for everyone resulting in lower form abandonment rates, increased interactivity and the potential to increase revenue.

Why are accessible forms important?

If forms are implemented accessibly everyone will reap the rewards. This helps people to identify the purpose of any given piece of content, regardless of the method that they use to access the web.

Let’s take the case of a visually impaired person using a screen reader as an example. In the context of web browsers, most Windows based screen readers have two modes of operation – browsing mode and forms mode. Browsing mode allows the user to traverse a web page using keystroke combinations which are mapped to shortcuts and other commands. Forms mode, on the other hand, temporarily unbinds these shortcut mappings and allows the user to enter information into form fields. Within forms mode, the user can move the cursor between form fields on the page, but cannot easily access surrounding textual information. This could potentially make it difficult for screen reader users to identify form labels, and thus the intended purpose of the form field.

Thankfully, HTML provides a set of elements and attributes intended to make the process easier for everyone. For example, if form labels are marked up correctly, screen readers will announce the form label when the cursor is moved to the corresponding form field (more on this later). HTML elements are frequently chosen for the way that they appear visually as opposed to their underlying semantic meanings (when I refer to “semantic meaning” I am making the distinction between the visual presentation of elements and the meaning implied by the elements type).

So why don’t people make use of this functionality as much as they should? Simply put, I just don’t know! Some content management systems certainly have technical limitations that inhibit the ability of developers and content providers to produce conformant HTML. However, the majority of CMS platforms are flexible enough to provide a great deal of control for developers and content providers alike.

Popular content management frameworks such as Drupal can be used with a number of different templating engines, allowing the developer to select the one that provides the highest level of flexibility.  Other frameworks such as Django provide easily extendable template engines with a high level of flexibility out of the box.

The three rules of improving web form accessibility

The most frequently encountered issues associated with web forms are incorrect use of:

1. Labels
2. Fieldsets
3. Legends

Labels

Form labels are textual indicators that should be bound to relevant form fields. These labels should identify the purpose of the field (what information is required) and should be provided for all form fields. I frequently encounter web forms where all of the labels used to identify fields are marked up as bold text and positioned adjacent to the corresponding field.

Example code

Your First Name

This approach to providing form labels is fine for people with good sight who can identify the relationship between form label and form field spatially. However, since there is no explicit binding between the label and its form field, visually impaired users will not find it so easy to identify these relationships.

To do so, a visually impaired user will have to repeatedly switch between forms mode and browsing mode in order to read the surrounding textual content and find the form labels. If labels are implemented correctly the experience for blind people using a screen reader will be drastically improved. If you look at the code example below you should notice that the label element has a for attribute that is identical to the id attribute of the corresponding form field. This ensures that the label is bound to its form field.

When forms and labels are bound to one another using this method, screen readers automatically announce label text when focus is moved to the corresponding form field. This is equivalent to a sighted person glancing at the label text as they move to the form field in question. It is easy to see how the majority of visually impaired users would prefer this to being forced into performing monotonous navigational actions in order to identify the purpose of every form field provided. Ensuring form labels and fields are explicitly bound to one another also has another benefit: if a correctly bound form label is clicked the cursor will be moved to the bound form field automatically.

This functionality is useful for people who have motor impairment diseases or poor hand to eye co-ordination. This effectively ensures that the form label acts as an extended hit area for the form field creating a better all round user experience.

Example of accessible code

Your First Name

Fieldset and Legend tags

HTML provides another set of tags that can significantly improve the user experience for people accessing the form. These tags are the