If ever there were a good candidate for a “too much accessibility” award, the FIELDSET LEGEND element would surely take some beating.
Yes yes, I know, if you don’t have a LEGEND on your FIELDSET, some automated accessibility checkers will throw it up as an error. Well, my answer to that is, they don’t have to listen to them!
By this, I don’t mean that LEGEND should never be used, but like everything else in the accessibility toolbox, it’s not what you use, but how you use it.
The right way is to choose LEGEND text that is:
- Concise: between 1 and 6 words.
- Relevant: to every single form field in the FIELDSET.
- Seamless: in that the words chosen for the LEGEND should make sense when joined to each label phrase. This might take a bit more explanation, so read on and you’ll see why.
LEGENDS that fail any of the above are likely to cause confusion, headaches or even a fit of the screaming abdabs, in screen reader users.
The reason is, and read this twice, it’s important: LEGEND text isn’t read at the start of the FIELDSET, it is read at the start of the label. It repeats at the beginning of every single text label in that FIELDSET.
Let’s just examine those important rules again, and see what can happen if they’re ignored:
- If not concise: it can take an inordinate length of time to get to the question in the label, and there’s no way to skip straight to it.
Believe it or not, I’ve seen LEGEND text that was 48 words long. This repeated at the start of all 30 questions in that particular FIELDSET. This made the form impossible to complete, because attention switches off after a certain amount of repetition, and then the label itself gets overlooked.
- If not relevant: conflicting or confusing information can be conveyed when the LEGEND isn’t appropriate to every label.
For instance, on an e-card sender page, the first FIELDSET grouped the sender and the recipient names and e-mail addresses, using the LEGEND “Your personal details”. This worked fine until it came to the label for the recipient’s name; the label was “Send to:”.
“Your personal details, send to:” sounds as though some privacy is about to be put at risk. :)
- If not seamless: the combined sense of the LEGEND and label might be difficult to unravel, or worse, might sound to screen reader users as though the web author was drunk.
A couple of examples, the first being a numbered list of checkbox options::
LEGEND: “What did you come to this site for”
1 to buy clothes
2 to buy accessories
3 for store addresses
4 for other informationQuestion 4 comes out particularly garbled as:
“What did you come to this site for four for other information”.A more common nasty is where the word, “Your” is used; in both the LEGEND and the text label, e.g. “Your details: Your name”, “Your details: Your address”, “Your details: Your age”. Sounds stupid put together, doesn’t it?
To avoid all of the problems described here, all you need to do is one thing. Once the form is finished, read aloud the chosen LEGEND and each text label in its FIELDSET, as a single sentence. If it doesn’t make perfect sense, think again.
Gary Hides | 08/11/2006 at 22:21 | Permalink
I see your point and agree that if the LEGEND is read out before each LABEL, that would be really annoying and cause you to switch off etc. But, I don’t think the problem here is with the web designers who use the LEGEND tag in such a way as you have described. It would seem to me that the screen reader is wrong to read out the elements in such a way.
The W3C quite clearly state that the FIELDSET tag is for grouping sets of form elements together. Therefore, I would take the LEGEND as a description for the set of elements contained within the FIELDSET, not as a prefix to any LABEL elements contained in the FIELDSET.
Do all screen readers work in this way? I’d be quite interested to know. Because if this is how the W3C intended the LEGEND tag to be used, then obviously a lot of web designers are thinking quite differently. If on the other hand the screen reader makers have got it wrong then it needs bringing to their attention and rectifying.
This is certainly something we’re going to have to look out for in future though. Information like this is great for us web developers who don’t use screen readers on a day-today basis and therefore don’t really know how all of the tags are read out.
Bim | 09/11/2006 at 17:18 | Permalink
Hi Gary,
Thanks for the kind comment.
I don’t see that the W3c intention and the JAWS screen reader implementation are necessarily at odds; JAWS has a “duty” to keep users informed that they are in the same group, and this is one way of achieving it.
I don’t know about other screen reader behaviour when encountering the LEGEND element, perhaps other screen reader users could let us know.
Alternatively, if anyone can suggest a better way of prompting screen reader users in a less repetitive manner, that would be useful too.
I have to say though, that when the LEGEND is concise, relevant and seemless, it really is a help. Keeping focussed, especially in long forms is a bit of a challenge if you cant just glance up the page a bit to remind yourself which group you’re in.
Philipppe | 10/11/2006 at 10:06 | Permalink
Hi Bim,
Thank you for focusing our attention to the FIELDSET LEGEND. It is so easy to forget to test every tag and to just look at the bigger picture. I will definetely pay more attention to LEGEND from now on.
I had clearly assumed that the FIELDSET LEGEND would behave like a TABLE LEGEND that is: as a synthetic text to be read only once and certainly not before every piece of data.
Bim | 10/11/2006 at 10:31 | Permalink
A fair assumption. I suppose the reason it doesn’t is to avoid the potential nead to navigate away from the current field to get a reminder of the context.
This is probably reasonable, as there can be so many form controls in a FIELDSET, getting back to the right question may be time-consuming and missing out on any is likely to invalidate the form.
Gary Hides | 10/11/2006 at 13:51 | Permalink
Hi Bim,
I will definitely be making sure where we use the LEGEND tag in future, we try and make it as seamless and helpful as possible. However, I do still think the screen reader technology could be altered slightly to let the user know where they are without being so repetitive, such as reading out:
“Start of Your details
…the fields for Your details fieldset here
End of your details”
With hundreds of articles on the web about accessible forms, many people will come to form the impression that I and Phillipe did. And with a slight change in the way JAWS keeps the user informed of their position in a form, the annoyance factor could be dropped signifcantly.
Also, what about when you have a FIELDSET within a FIELDSET? How does the screen reader act then? Does it just read out the immediate LEGEND, or all of the parent LEGENDS?
We’re going to be visiting the Shaw Trust in Wales soon, to see the accessibility user testing in action for ourselves. This will obviously gives us a much better idea of how the assistive technology works, rather than just guessing from what others have written.
Thanks again for the info.
Bim | 10/11/2006 at 14:27 | Permalink
Thanks for being so positive about it. Every little helps! :)
Don’t know what would happen with nested FIELDSETS, I’ll do a test and feed back results.
I do take your point about having screen readers announce just the start and end, but think there would need to be a mechanism for a reminder, without moving from the current field. Along the lines of the prompt for header row and column information, which JAWS users can get from anywhere within a data table.
Still never want to listen to another 48 word LEGEND though. :)
patrick h. lauke | 11/11/2006 at 16:29 | Permalink
in essence, isn’t the problem here shoddy user agent / assistive technology, rather than a problem with the idea of legends themselves? could be an interesting thing to bring to the attention of screen reader developers.
p.s.: tabbing order on this comment form is screwy, as with most out of the box wordpress installs…
Bim | 13/11/2006 at 21:30 | Permalink
Bit of a catch-up to do. First a quick response to Patrick’s post, then I’ll give you the news on nested FIELDSETS and the behaviour of a screen reader other than JAWS.
It might be a bit harsh using the term sloppy implementation, when the aim is to give sufficient support for a wide range of needs Patrick. The LEGEND reading can be switched off using the verbocity settings, but for those people who need the prompts, excessively long LEGEND is a bind. There is a case for having a ‘halfway house’ where the LEGEND is read just once though.
You’re right, there is no problem with the idea of LEGENDS themselves. They’re great. Just as long as there aren’t essays within the LEGEND tags.
To answer Gary’s question, when FIELDSETS are nested one inside another, only the LEGEND of the immediate containing FIELDSET is read aloud.
I’ve had an answer to the “other screen reader behaviour” question, from a SupaNova user. It does the same as JAWS, reading the LEGEND at each form field.
Gary Hides | 14/11/2006 at 9:43 | Permalink
Thanks Bim,
I think we have a much clearer understanding of what is happening at the LEGEND/LABEL stage of a form now.
Thierry | 30/11/2006 at 6:03 | Permalink
Thanks, I had no clue.
Tim | 30/11/2006 at 6:33 | Permalink
Thanks, I thought I was sort of there with a simple accessible form but I was not sure why before you explained it to me, thanks:
Does having a “tabindex” help form navigation when using JAWS or any other text reader?
I could only get “tabindex” to work in Netscape, Mozilla and Firefox ignores them on Mac OSX
http://www.hereticpress.com/Dogstar/Publishing/ContactHP.html#skipnav
thanks
Tim
Yecril | 09/05/2007 at 16:33 | Permalink
What the screen reader really should do is to read the legend once at the beginning and read it on demand in the middle.
Bim | 09/05/2007 at 19:01 | Permalink
That’s a very good point. You would have thought that this should be possible, it’s similar to what happens in tables. Users don’t have to listen to headers on every cell they land on, they can query for it when they want it.
J.Sexton | 28/06/2007 at 0:00 | Permalink
Very good point, I will contact Dolphin to see if anyone has previously requested such a feature. Like you said, its already available for tables so why not forms?
I’ll post their response back here.
kuppu | 08/12/2007 at 14:09 | Permalink
can we able to do fieldset for a single row containing more elements