Using the right HTML elements when implementing forms is essential to ensure they can be used by as many people as possible including screen reader users. In this blog Léonie explains the correct usage of the fieldset and legend elements.
On GOV.UK we often use groups of related form fields, like a set of radio buttons or checkboxes. These related fields might be used to offer multiple answers to a single question, or to ask for multiple pieces of information about the same thing.
Questions with multiple choices
For example, when the answer to the question is a simple "yes" or "no":
<form>
<p>Do you have a passport?</p>
<input type="radio" id="yes">
<label for="yes">Yes</label>
<input type="radio" id="no">
<label for="no">No</label>
...
</form>
In this example the question sits above the set of radio buttons, and visually it is clear that the question relates to the group of form fields. If you cannot see the page, this relationship is lost however. If you use a screen reader to choose one of the radio buttons, you will hear the form labels being announced ("Yes" or "No"), but you may not hear the question announced at all. This is because the question is not associated with the set of radio buttons within the code of the page.
Quick recap: screen readers get most of the information they need from the HTML code of the page. The browser takes the HTML code and converts it into accessible information that can be used by assistive technologies like screen readers. This article on Accessibility APIs: a key to web accessibility has more information.
If you use the arrow keys to guide your screen reader through the form you will hear the question announced. This is not an efficient way to navigate through a form though, so most screen reader users choose to use the tab key instead. But it is when you use the tab key to navigate through a form that the question is not announced - making it difficult to know what the correct answer might be!
We fix this by using the <fieldset> and <legend> elements. These elements work together to tell screen readers that a group of form fields relate to each other, and to provide a label for the group.
All of the related fields go inside the <fieldset> element, and the <legend> element is used to represent the question instead of the <p> element.
<form>
<fieldset>
<legend>Do you have a passport?</legend>
<input type="radio" id="yes">
<label for="yes">Yes</label>
<input type="radio" id="no">
<label for="no">No</label>
</fieldset>
...
</form>
Now when you use the tab key to navigate through the form, your screen reader will announce the question before it announces the first field in the group and its label. So in our example you hear something like "Do you have a passport? Yes, radio button".
Note: when used with Internet Explorer, the Jaws screen reader will announce the legend for every field in the fieldset (not just the first field). This is not the expected behaviour.
Questions with related answers
The <fieldset> and <legend> elements are also used when there are multiple questions about the same topic.
<form>
<fieldset>
<legend>Your address</legend>
<label for="street">Street</label>
<input type="text" id="street">
<label for="town">Town or city</label>
<input type="text" id="town">
<label for="county">County</label>
<input type="text" id="county">
<label for="postcode">Postcode</label>
<input type="text" id="postcode">
</fieldset>
...
</form>
It is possible to nest one <fieldset> element inside another, but it is not recommended. Screen readers do not automatically indicate the end of the <fieldset> element, so it is impossible for screen reader users to confidently know which fields belong within which fieldset.
When to use a fieldset and legend
You should use the <fieldset> and <legend> elements when:
- You have a single multiple choice question (using radio buttons or checkboxes).
- You have several questions relating to the same topic (like text boxes, or any other type of field).
When not to use a fieldset and legend
You should not use the <fieldset> and <legend> when:
- You have a single form field that asks for a single piece of information.
When used correctly, the <fieldset> and <legend> elements tie related form fields together in a way that is accessible to people who cannot see the visual layout of the form.
Follow @LeonieWatson on Twitter and don't forget to sign up for email alerts.
20 comments
Comment by Eric Eggert posted on
More on grouping form fields can be found in this W3C WAI tutorial: http://www.w3.org/WAI/tutorials/forms/grouping/
Comment by Leonie Watson posted on
A question was asked on Twitter about screen reader support for nested fieldsets. There is more information available here:
http://ljwatson.github.io/test-cases/nested-fieldsets/
Comment by Adam Silver posted on
In your demo page the problem, it seems with the nested fieldset is that the "Phone" field comes *after* the nested fieldset.
1. Is that the only problem with a nested fieldset to your knowledge?
2. When a form field is contained within a nested fieldset, my expectation/assumption is that both legends will be announced. Is this:
a) a correct assumption?; and
b) if so, does it work like this in the wild?
Reason for these questions is not just theoretical. I have a demo page setup (link provided below):
http://adamsilver.github.io/kitty/src/demos/nested/index.html
It uses two fieldsets to organise time choices. The first legend is "date and time" and the second legend (for which there are multiple) is, for example, "Monday 23 October".
Comment by Léonie Watson posted on
"1. Is that the only problem with a nested fieldset to your knowledge?"
Indirectly, yes. The problem is that screen readers don't indicate where the fieldset ends. If you have a form something like this:
<form>
<fieldset>
<legend>Group 1</legend>
//field 1
//field 2
<fieldset>
<legend>Group 2</legend>
//field 3
//field 4
</fieldset>
//field5
</fieldset>
//field6
</form>
So as a screen reader user tabs from field 4 to field 5, they are given no indication that the inner fieldset has ended but that the outer fieldset remains open. Similarly when focus moves from field 5 to field 6, they are given no indication that the outer fieldset has closed either.
"2. When a form field is contained within a nested fieldset, my expectation/assumption is that both legends will be announced. Is this:
a) a correct assumption?; and
b) if so, does it work like this in the wild?"
No, screen readers don't concatonate the legends. Only the legend for the parent fieldset is announced. So in this example, when focus moves to field 3 the "Group 2" legend would be announced, not the "Group 1" legend.
Comment by Adam Silver posted on
Thanks Léonie.
That leaves me with one remaining question.
In my demo, all radio buttons are inside the inner fieldset. There are no radio buttons inside the outer but not the inner fieldset. I hope that makes sense.
In this case, and in my demo, does this mean it works well?
Comment by Léonie Watson posted on
"In this case, and in my demo, does this mean it works well?"
The fieldset problem for screen reader users isn't an issue for your form, no.
Comment by goetsu posted on
You may need to add an unique id on the legend and an aria-describedby on the input if you want Voiceover on iOS support like :
<form>
<fieldset>
<legend id="passport_question">Do you have a passport?</legend>
<input type="radio" id="yes" aria-describedby="passport_question">
<label for="yes">Yes</label>
<input type="radio" id="no" aria-describedby="passport_question">
<label for="no">No</label>
</fieldset>
...
</form>
Comment by Leonie Watson posted on
Thanks Goetsu. We thought about using ARIA to fix the VoiceOver issue with iOS. We came up against some interesting complications though...
The expected behaviour is for the legend to be announced when focus moves to the first (and only the first) field inside the fieldset. The "first" field changes though, depending on the direction of navigation. It also changes when there is a set of radio buttons inside the fieldset and one of them is selected.
Take a fieldset containing a set of five radio buttons: we'd need to put aria-describedby on the first radio button, the last radio button, and either dynamically add it to whichever radio button was selected (assuming it wasn't one of the two radio buttons that already had aria-describedby applied) or apply it to every field just in case.
This would fix the VoiceOver/iOS bug, but it would also cause every screen reader to announce the legend for every single field inside the fieldset. That's a lot of extra verbosity, for a lot of people.
The legend is accessible to VoiceOver on iOS as you navigate through the content. It just isn't announced when focus moves to the first field or when you use the roter to access form fields. So the choice becomes a usability choice - and not an easy one at that. Thoughts very welcome 🙂
Comment by James Edwards posted on
That extra verbosity though -- that's already the case for JAWS/IE users, as you noted. And since JAWS/IE is a majority of screenreader users, maybe that's an argument for saying that using LEGEND/FIELDSET creates an overly verbose experience in general?
Comment by Leonie Watson posted on
It would be good to do some research to find out whether this behaviour adversely affects usability for Jaws + IE users, before imposing it on other groups of people.
Comment by James Edwards posted on
Oh I wasn't suggesting imposing that behaviour on other groups, I was suggesting not imposing it on JAWS by not using fieldsets and legends at all 🙂
Comment by Allen Simon posted on
It's amusing that your one no-no is using a fieldset for a single question, yet your core example in the article is a single yes-no question. Surely there are other tools (such as the "title" attribute) which you could use for accessibility. Anyway, for a single question it's easier to just have answer buttons rather than radios with a separate "submit" button.
Comment by Léonie Watson posted on
I probably didn't phrase it that well. The fieldset/legend elements are not needed for a single question where the question is contained within the label for the field.
The title attribute wouldn't be appropriate in this case. It forms part of the accessible name computation, and so if present it effectively overrides the label element. The title attribute is also not <a href="https://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/">particularly accessible</a> for other reasons.
It would be possible to use buttons, but buttons do not toggle on/off like radio buttons do. You'd need to replicate the radio button behaviour so that only one button could be selected at a time. You'd also need to provide additional semantics to inform screen reader users which button was currently pressed.
Comment by Nimesh Gurung posted on
Recently did some work on making a web form accessible and this really caught me off guard, as the `radio` and the `checkbox` controls did not have any surrounding `fieldset` and `legend`, and there was no context to the `input` controls from a voiceover prespective. It's good to see documented here. How do you guys normally debug accessibility issues, is it just trial and error?
Comment by Léonie Watson posted on
Glad this post was helpful!
We try to follow standards as much as possible. For example, if there is an HTML element designed to do the thing we want, we'll try to use it. The theory is that browsers and assistive technologies also try to follow standards, so it should give us some common ground.
In real life there are always differences between browsers and assistive technologies when it comes to accessibility (as with everything else). We encourage usability testing with people who use assistive technologies, as a way to uncover potential problems.
Once an issue has been identified, it's a matter of trying to find the cause, and from there of trying to find a solution that fixes the problem without having a negative impact on someone else's experience.
If you work inside UK Gov, I recommend joining the Accessibility Community Google Group. Otherwise, the A11y Slackers Slack/Gitter channel is another good place to talk about technical accessibility with other people.
Comment by Nienke posted on
Wonderful post - I never even thought of this, shamefully. Thank you for sharing and making the web a better place!
Comment by Léonie Watson posted on
Thank you! Glad you found it helpful.
Comment by Mark posted on
Using the correct design and template suitable code makes your website clean and looks feel good. I appreciate author a such a cool post on fieldset usage which always makes different in HTML coding
The complete html site with errors free code: mypsdtohtml.com
Comment by paul posted on
Is it ok to nest the input into the label and thus removing the "for" element that links the label to the input
for example:
<form>
<p>Do you have a passport?</p>
<label>
<input type="radio" id="yes">
Yes
</label>
<label>
<input type="radio" id="no">
No
</label>
...
</form>
Comment by Patrick posted on
I'm struggling with the usage of the fieldset and legend elements. I got 3 radio buttons and it's a required answer. How can I manage this situation?