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

<b>Your First Name</b>
<input type="text" name="fname"/>

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

<label for="first_name">Your First Name</label>
<input id="first_name" type="text" name="fname"/>

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 <fieldset> and <legend> tags. These are used to group and describe the purpose of related form fields, effectively providing a context from which the following fields can be understood.

Fieldsets

Fieldset tags are used as a mechanism for grouping related sections of forms.  Correctly implemented <fieldset> tags have benefits for various people.  By default <fieldset> tags provide a visual outline around the form field grouping.  This can be extremely beneficial for people with cognitive disabilities as it effectively breaks the form into smaller subsections, making the form easier to interpret in the first instance. 

So why is it not valid to wrap forms in appropriately styled <div> tags? A <div> element with a border would certainly provide the same visual distinction as a <fieldset> grouping, however, <div> tags do not provide sufficient semantic information for assistive technologies to utilise.

Assistive technologies such as screen readers provide varying degrees of functional support for <fieldset> and <legend> tags. While some will ignore the groupings, providing no extra benefit, other screen readers will identify a fields form grouping when it gains focus, announcing the text within the corresponding <legend> tag before the fields label.

This is a useful accessibility feature as it provides a context from which the form label can be understood. Although support amongst assistive technologies varies significantly, it is good practice to use the <fieldset> and <legend> tags as opposed to <div> and <p> or heading tags. Doing so is certainly not detrimental to the experience for the majority of people, and will ensure that people using technologies that effectively support these elements have access to the added accessibility information that they provide.

Legends

The <legend> tag should be used to provide descriptions of the form groupings on the page. For any given <fieldset> there should always be one associated <legend> tag. This should appear directly after the opening <fieldset> tag and should provide a descriptive context from which the purpose of following form fields can be identified. If legend tags are not implemented effectively, people with cognitive disabilities may find it hard to identify the context of the form, and hence the purpose of the form fields that follow are more likely to be ambiguous.

Using Fieldsets and legends

Consider the code and screengrab below. The form groupings are wrapped using <div> elements. The descriptions of these groupings are wrapped in <p> tags.

  

    
Broadband Payment Form
    

      
Your broadband account
      First Name
      
      Surname
      
      Account Number
      
    
 
<div>
  <p>Your banking details</p>
  <label for="aNum2">Account Number</label>
  <input id="aNum2" type="text" name="aNum"/>
  <label for="eDate">Expiry Date</label>
  <input id="eDate" type="text" name="eDate"/>
</div>

  

Now consider the code and screengrab below. You should notice that fieldset tags have been nested within one another and that the legend tags have been used to describe related field sets.

  

    
Broadband Payment Form
      

        
Your broadband account
        First Name
        
        Surname
        
        Account Number
        
      
 
  <fieldset>
    <legend>Your banking details</legend>
    <label for="aNum2">Account Number</label>
    <input id="aNum2" type="text" name="aNum"/>
    <label for="eDate">Expiry Date</label>
    <input id="eDate" type="text" name="eDate"/>
  </fieldset>

   

The relationships in the second form should be easier to identify, since the default styling of the fieldset has not been removed which helps to make them visually apparent. This should make it easier to identify the difference between a required bank account number and a broadband customer account number whilst making it possible to keep the form labels concise (There is no need to have a label such as "Your bank account number" since the section in which it appears is identified as relating to the users banking details via the <legend> tag).

Conclusion

Failure to use the HTML elements mentioned in this article effectively can create issues for accessibility making the form filling process a frustrating experience for people with disabilities.

Possible effects of this include higher form abandonment rates and dissatisfaction amongst some of your website visitors. In extreme cases, if a service is inaccessible to disabled users they are entitled to threaten the website owner with court action. Although most developers provide adequate information about web based forms it is common place for many of these developers to make use of elements that do not reflect the type of information that is being presented.

Since HTML provides functionality to assist with accessibility out of the box, developers should make a concerted effort to mark up web based forms according to best practise. So, what can you do to ensure your web forms are accessible?

1. For larger or complex forms, ensure that each form or discrete section of the form is wrapped with <fieldset> tags;


2. For every set of fieldset tags ensure that a descriptive legend tag is provided immediately after the opening fieldset tag;


3. For every form field, ensure that a descriptive label is provided and that it is bound to the form field using identical id and for attributes.

Adhering to these three basic guidelines will ensure your website is one step closer to meeting the accessibility standards set out in the WCAG 2.0 guidelines and will make it easier for people to make use of your website regardless of any physical, cognitive or technological limitations they may experience.

If you'd like to discuss how Nomensa can help you improve your UX, please contact us and a member of our team will get back to you.

Further reading

• Aesthetically pleasing accessible form design (opens in a new window)


• More tips for creating accessible web forms 


• The UX of forms part one - The reservoir of goodwill


• The UX of forms part two - Pace and balance

Tutorials

• Beginner (opens in a new window)


• Intermediate (opens in a new window)


• Advanced (opens in a new window)

Start building accessibility into your projects at the beginning to save time and money, don’t just leave it hanging on the backlog letting it gather up dust. Drill it in.

If you would like Nomensa to help you with your accessibility challenges or to provide you with an accessibility evaluation of your website/mobile app, please don’t hesitate to get in touch.

You can give us a call on +44 (0) 117 929 7333 or submit this short form. In the meantime, take a full look at the digital accessibility services that we offer.