Italian translation Fieldset, Legend e Screen Reader by Roberto Castaldo.
The grouping and labelling of thematically related controls within a form is an important aspect of providing semantic information so users can understand and complete a form successfully. Differences in quality and implementation of support across user agents can hamper some users’ ability to benefit from this information. This must not be taken as disincentive to developers, as the benefits of using these elements outweighs the negatives. But it is clear that some assistive technology vendors need to improve implementation of HTML features that enhance accessibility, so their users can gain the most benefit.
Using the fieldset and legend elements
The HTML 4.1 specification provides a method for grouping and labeling related form controls. This capability is provided by the use of the
fieldsetelement allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.
legendelement allows authors to assign a caption to a
fieldset. The legend improves accessibility when the
fieldsetis rendered non-visually.
Whenever a label is needed to provide information about a related set of controls consider using the
fieldset elements. They can be used to group any thematically related controls in a form such as address details, date of birth and sets of radio buttons or check boxes.
Note: It is required that the
legend are used in conjunction. A
fieldset cannot be used without a
legend and visa versa.
<input type="radio" name="filter" id="a">
<input type="radio" name="filter" id="b">
<input type="radio" name="filter" id="c">
Presentation to users
The default rendering of the
legend elements is fairly uniform across the major visual browsers. The
fieldset is displayed with a solid border and the
legend text is overlaid on the top left border. This provides a clear visual indication of the controls that are contained within the group and the caption (legend) that applies to the grouped controls.
Default visual display in Internet Explorer, Firefox and Opera
For visual users, the association can be represented by the position of the legend and the enclosing of related controls within a bordered box. How should non visual user agents such as screen readers convey the structural associations provided by the legend and fieldset elements? The most important relationship is that of the
legend text to the individual controls contained in a fieldset, as the legend serves to describe the context of the data or choices required. As the content is accessed linearly by screen readers, the apparent simple visual association is not so easily or clearly expressed.
The UAAG 1.0 (User Agent Accessibility Guidelines) provide this advice on implementation:
HTML 4 specifies the FIELDSET element , which allows authors to group thematically related elements and labels. The LEGEND element assigns a caption to a
FIELDSET. For example, the
LEGENDelement might identify a
FIELDSETof radio buttons as “Connection Rate.” Each button could have a LABEL element, stating a rate. When it receives content focus, identify the radio button as “Connection Rate: Radio button X of Y: 28.8kpbs”, where “Y” represents the total number of radio buttons in the grouping and “28.8kbps” is the information contained in the
With this implementation advice in mind, 2 of the major screen readers were tested using an example
fieldset containing 3 radio buttons labelled “television, radio, cinema” with a
legend of “filter by”. It was found that what is announced varies depending on the software, mode and navigation keys used.
In Virtual PC cursor and Forms mode the
legend is announced when each of the controls contained in a
fieldset receive focus.
virtual PC cursor ‘browse’ mode
If the user moves through the content using a “Say All” (ins+down arrow) command or “Say Next Line” command (down arrow), the
legend is announced when intitally encountered, but no indication of association to related controls is provided:
filter by radio button televsion, radio button radio, radio button cinema
If the “Move To Next Form Field” (F) command (only available in ‘browse’ mode) is used to move through radio buttons within the
fieldset the result is different:
filter by radio button television, filter by radio button radio, filter by radio button cinema
The results for navigating through controls contained within the
fieldset are the same as when the “Move To Next Form Field” command is used, the
legend text is prefixed to each control label contained within the fieldset.
Using the default settings no indication of the
legend is announced in any mode. For the user to be made aware of the presence of a
fieldset, the user must first modify the Window Eyes browse mode verbosity settings
Insert Beginning / End Message (Fieldsets) This option will notify the user of both the beginning and end of a
Browse mode – announce fieldset option enabled
When this option is enabled, if the user navigates using the down arrow, the start and end of the
fieldset is announced as is the
filter by fieldset start radio button television, radio button radio, radio button cinema filter by fieldset end
The user can also navigate using the “Next Fieldset” (E) and “Previous Fieldset” (shift+E) commands. When these commands are used, the end of a fieldset is not announced. If the “Next Control” (C), “Previous Control” (shift+C) or the TAB key is used to navigate,
legends are not announced.
When using Firefox, Window Eyes does not recognize or announce the presence of the
legend elements. So for example, when using the “Next Fieldset” (E) command “no fieldset” is announced.
Browse mode off (forms mode)
When the user is not in browse mode (has to be disabled to for the user to interact with edit boxes, text areas and dropdown lists) the user is confined to navigating through controls using the TAB key and no
legend information is announced.
- JAWS 8 and Window Eyes 5.5 were used for testing. The fieldset test page was viewed in Internet Explorer 7 and Firefox 2 on Windows XP.
- The examples of screen reader output have been edited to include only pertinent announcements.
legend elements are a useful part of a web developer’s toolkit for making forms more accessible to people with disabilities. The support in Window Eyes is quite different from the advice given in UAAG1.0. Due to this, Window Eyes users will not be able to gain the full benefit of the additional information provided through the use of these elements. In fact no
legend text will be announced to users unless they first enable an option to announce such information. Even when the option is enabled Window Eyes users will not receive this important information when they are inputting data into form fields. Furthermore if they use Window Eyes in conjunction with the Firefox browser no
fieldset information will be provided.
The situation for JAWS users is much better. The JAWS implementation is consistent with the advice in UAAG 1.0. The grouping of controls using the
fieldset is not explicitly announced (as it is in Window Eyes), but the announcing of the fieldset is not advised in UAAG and may be of limited value or overly obtrusive for the users, which could be why it is not enabled by default in Window Eyes. Importantly the association of
legend text with controls contained within a
fieldset is reliably conveyed by the announcement of the
legend along with a control’s text label. This behaviour works when the user is browsing or interacting with form fields and across supported browsers.
Due to the nature of the advice in UAAG 1.0 and its implementation in JAWS (legend text being announced before a control’s label text), developers should be mindful of the length of
legend texts, as lengthy
legend texts have been found to make forms difficult to use. Another potential pot hole is the JAWS behaviour when headings are included within a
fieldset. In this case JAWS will typically use the heading text in place of the
legend text, this is a quirk or bug, which can lead to unexpected and problematic consequences. This needs to be fixed in JAWS, but until it is, perhaps the use of headings within fieldsets should be minimised.
legend elements are well supported by many user agents. While it is helpful to have knowledge of some of the quirks and failings of particular user agents, the poor support in software such as Window Eyes must not stop developers using these elements or accessibility practitioners recommending their use. Their use can make it easier for a wide range of disabled users to fill out forms. In order to improve accessibility for all disabled users, web standards must be adhered to so that developers can code for accessibility with confidence. It is the assistive technology vendor’s job in these cases to fix their implementations.
Great post Steve, very well explained. It’s a shame about the implementation of headings inside fieldsets, isn’t it? The advanced JAWS user doesn’t get the announcement of LEGEND content unless they specifically enable it, and these users often rely on headings for context.
One thing to emphasise is that nesting FIELDSET elements is also OK, and is often necessary to avoid confusion. For instance where there is a sub group of controls within a fieldset. One example I’ve come across in a job application form grouped all details for each referee in FIELDSET elements, including a question relating to when the reference could be taken up. The FIELDSET LEGEND was “Reference 1 for all details about the first referee.
On reaching the permissions question, which used checkboxes for “Yes” and “No”, instead of hearing the question “May we take up this reference before your interview?”, the screen reader announcement was “Reference 1: Yes” and “Reference 1: No”.
Without coming out of forms mode, the user wouldn’t know that this wasn’t confirmation that the details just given related to the first reference.
In this case a nested FIELDSET with the LEGEND “Can we write prior to interview?” would have provided at least a clue to the purpose of the question. Although using SELECT options instead of radio buttons would have worked just as well.
Thanks Steve, very clear and well explained.
A quick comment on nested fieldsets and something I have noticed in the past. Say you have a fieldset (F#1) with a bunch of questions and inside this fieldset you nest another fieldset (F#2) however after this nested fieldset (F#2) you have a couple of questions that relate to the main fieldset (F#1) legend. When a situation like this is accessed with JAWS 7.10, it appears that the screen reader associates these extra questions with the legend for the nested fieldset (F#2) rather than the parent fieldset (F#1). In other words, it looks for the legend that becomes immediately before the input and appears to ignore the fact that the nested fieldset has been closed.
Sorry about the convoluted explanation, but I wonder if anyone else has had this experience.
Good article Steve. It’s a useful introduction to how to correctly use these elements. I also like the way you demonstrate the linear output of the screen reader in text form.
Interesting comments from Bim and Roger. I have never used nested fieldsets so can’t comment, but I guess a way around the JAWS bug, when using headings inside a fieldset, is to place a suitable heading before the fieldset element and when the user extracts the headings using
INSERT + F6or by pressing H and gives the heading focus then by tabbing again – the fieldset should successfully receive focus and the user can then navigate through it in the usual way.
Thanks for the article.
Maybe I am missing something [which is a very real possibility], wouldn’t the use of text that is hidden via a CSS ‘Black Hole’ technique [not using
displayelement] solve some of the rendering ambiguities within assistive technology user agents?
I feel the same way about your comment.
How does “the use of text that is hidden via a CSS â€˜Black Holeâ€™ technique [not using display element] solve some of the rendering ambiguities within assistive technology user agents” relate to what is written in this post?
I am simply asking the question of whether or not the use hidden text could not resolve some of the issues and complexities, that you have pointed out within various user agents, i.e. in either not rendering HTML tags or only doing it via some detailed software user settings. I view the essence of your post that proper use of
legendis to provide the user with orientation and bearings within the Web content. A logical addition to that might be to use hidden text to help provide that orientation. If I am wrong in my assertion, assumptions or whatever let me know so that I may stand corrected.
Thank you very much.
I don’t see how the addition of hidden text (for a user agent that has poor support for legend/fieldset) would help, as this would lead to duplication of information for users of user agents that support it correctly, which could in fact lead to a degradation of the user experience. The issue with Window Eyes is one of poor implementation, users need to be advised to turn on the announce fieldset option, while GWMicro need to improve the implementation so that legend text is available in forms mode and the announcing of legend text occurs by default.
Thank you very much.
I understand and appreciate your logic behind possible duplication of information. As I understand it, JAWS does not make it easy for a user to interpret
legend, either. I guess my view of accessibility is broader than content that is easily interpreted by those with just disabilities. Accessible content should, ideally, be totally user agent independent and device independent.
Regardless, thank you for this thread. It has helped me think and to think into the possible value of separate style sheet use that is targeted for specific need, user agent and device.
I think you should Provide some examples of Html&css