Three rules for creating accessible forms


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

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

  1. Labels;
  2. Fieldsets;
  3. Legends.


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.


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.


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.

<form action="some-script.php">
    <p>Broadband Payment Form</p>
      <p>Your broadband account</p>
      <label for="fName">First Name</label>
      <input id="fName" type="text" name="fName"/>
      <label for="sName">Surname</label>
      <input id="sName" type="text" name="sName"/>
      <label for="aNum">Account Number</label>
      <input id="aNum" type="text" name="aNum"/>

      <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"/>

Form implemented using div and p elements as opposed to fieldset and legend tags

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.

<form action="some-script.php">
    <legend>Broadband Payment Form</legend>
        <legend>Your broadband account</legend>
        <label for="fName">First Name</label>
        <input id="fName" type="text" name="fName"/>
        <label for="sName">Surname</label>
        <input id="sName" type="text" name="sName"/>
        <label for="aNum">Account Number</label>
        <input id="aNum" type="text" name="aNum"/>

        <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"/>

Form implemented using fieldset and legend tags appropriately

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).


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.

Further reading

Share this post

About the Author

Nomensa are experts in web accessibility strategy, web usability analysis, accessible website design, CMS procurement and implementation.


  1. Hi Dan

    Loved the article: a great combination of what to do, with clear explanation of why to do it.

    One very minor nitpick: in your double fieldset example, you say that there is no need to expand the ‘account number’ labels to say ‘broadband account number’ and ‘bank account number’, because the context given by the fieldset explains which account number you are asking for. Well, I sort of agree with that but not entirely. In the example of ‘account number, and given that this is rather a simple form, I think you’d be fine – so I’m not really disagreeing.

    But, but. I have frequently found that in similar examples, people do really need the label expanded (as well as being properly marked up, of course). Your forms will be used by people using screen readers, but also by lots of other people including some people with disabilities who do not use assistive technologies. So making the wording of each label as clear and unambigous as possible is really important. In particular, I have seen major issues where a box asks for ‘Name’, expecting people to understand that it’s not their own name from other cues in the context. Only, it’s easy to mistakenly assume that ‘Name’ without further explanation means your own name – especially if you’re stressed, in a hurry, confused by other difficult concepts in a form, or if you have a disability or specific learning difficulty such as dyslexia that makes the act of reading itself hard enough that you can’t give your full attention to understanding what the form is asked for.

    Bottom line: everyone, please do the right thing in your markup according to Dan’s explanation. But also think very hard about making sure that each label asks for exactly the information you want in a way that is as easy as possible to understand.

    Caroline Jarrett
    Twitter @cjforms

  2. Isofarro says:

    Be very careful of your legend text when using fieldsets, especially when nesting fieldsets. The rule is to keep legend text as succinct as possible.

    In the screenreaders my friends use the legend text gets prepended to each label in that fieldset. which means, the audible labels on each of the fields in the last example are:

    * Your broadband account First Name
    * Your broadband account Surname
    * Your broadband account Account number
    * Your banking details Account number
    * Your banking details expiry date

    This can perhaps be even worse when nesting fieldsets are used (I haven’t tested this in screenreaders – but it would be logical to read out the cascase of nested fieldset legends because they are grouping fields and fieldsets for a, perhaps contextual, reason) – so the worst case labels for example:

    * Broadband Payment Form Your broadband account First Name
    * Broadband Payment Form Your broadband account Surname
    * Broadband Payment Form Your broadband account Account number
    * Broadband Payment Form Your banking details Account number
    * Broadband Payment Form Your banking details expiry date

    Now the individual field labels are right near the end of each vocalised label, making skimming the form in a screenreader that much more difficult.

    Keeping the labels ultra succint would help. In your example above I strongly discourage the outer fieldset wrapper – “Broadband Payment Form” – since the forms purpose should already be contextualised either by a header prefacing the form before the screen reader enters forms mode, or by the page title if the form is the sole element.

    If the outer wrapper fieldset must be there, then reduce it to ‘Payment’ would certainly be more beneficial to screen reader users. If they can’t pick up the context of ‘payment for what’, that would indicate some bigger information architecture issues that need to be carefully resolved.

    In the inner fieldsets, definitely drop one of the words (most likely candidate is the ‘Your’ in both), going for ‘Your account’, or ‘Broadband account’.

    An alternative, that goes against the grain of the ‘benefits’ of fieldset legends is to blank out the legend text and add in some additional text into the label that clarifies context of a form. That text could be in a span, perhaps initially positioned offscreen (leftwards, not topwards) and styled as a tooltip when the field receives focus. That way, the label can describe it’s own nesting in a reverse format – most siginificant details – the field name – coming first, with the follow up text further clarifying (for example: “Account Number: (Bank)”)

    On a related subject, I’m interested in your views of using labels as a mechanism for linking form field validation error messages to actual form fields, or how best to go about creating accessible field error messages for form error handling.


  3. Alastair Campbell says:

    Hi Caroline & Mike,

    If you combine what you’re saying, are we better off (in a future-looking, blue sky sort of way) making each label fully defined, rather than using a grouping mechanism?

    From Caroline: some people won’t see/notice the grouping label (i.e. the legend).
    From Mike: Too much legend can be overwhelming.

    NB: In our testing recently, the way screen readers use legend is inconsistent at best, it’s hard to work out what their heuristic is, therefore Dan opted to outline the general best-practice.

    One thing that surprised me was the JAWs does not consistently read out legends in front of labels, at least for this case (nested) and even for the non-nested cases we tried recently.

    We could be in danger of creating conflict between audiences though, and it could be a case of over-doing it? As Caroline mentioned, it depends on the context and complexity of the form.

    I quite like the approach Egg used to take with it’s login labels:
    First Name (only) [____]
    Last Name [____]

    The “only” bit used to stop me putting my whole name in (due to habit), little touches like that can make all the difference.

    Regarding the errors & labels, it’s funny you should ask, I think my colleague Matt is creating an article that covers that question. In short, we tend to (when possible) put a general error message at the top, and errors in the labels next to each input. I’ll prod Matt to publish his article.

  4. Dan Stringer says:

    Hello Caroline and Mike,

    First of all, sorry for the delay in responding to your comments which have been greatly received. My coleague, Alastair, has pretty much covered off everything that I would have wanted to mention in response to your comments/queries. Indeed, the fieldset/legend examples provided in my original post are too simple to warrant use of the legend tag in this way and as such both of your points are valid ones. As mentioned by Mike, excessively verbose legends can damage the experience for people who use screen readers. However, ommiting them from your forms altogether can be equally damaging for other people (such as people with cognitive disabilities).

    I would agree that simple forms should not need to make extensive use of the legend tag. However, they can be extremely useful when effectively implemented in more complex forms. There is no point in making use of the legend element for its own sake. Rather, the end user should be the primary consideration during form design and implementation. There seems to be a balancing act between providing too much and not enough information when dealing with forms and as such use of the legend element needs to be considered on a case-by-case basis.

    Kind Regards,

  5. Wengfu Zhoudong says:

    Do have the interesting VB files for this lesson? I would like to download the VB files for fieldset and fieldArray types.


Add a comment

Fields marked with an asterisk (*) are mandatory.

Comment details