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 fieldset
and legend
elements:
The
fieldset
element 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.The
legend
element allows authors to assign a caption to afieldset
. The legend improves accessibility when thefieldset
is rendered non-visually.
Whenever a label is needed to provide information about a related set of controls consider using the legend
and 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 fieldset
and legend
are used in conjunction. A fieldset
cannot be used without a legend
and visa versa.
Example code:
<fieldset>
<legend>filter by</legend>
<input type="radio" name="filter" id="a">
<label for="a">television</label>
<input type="radio" name="filter" id="b">
<label for="b">radio</label>
<input type="radio" name="filter" id="c">
<label for="c">cinema</label>
</fieldset>
Presentation to users
Visual browsers
The default rendering of the fieldset
and 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
Screen Readers
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, theLEGEND
element might identify aFIELDSET
of 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 theLABEL
.
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.
JAWS
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
Forms mode
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.
Window Eyes
Using the default settings no indication of the fieldset
or 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 fieldset
option:
Insert Beginning / End Message (Fieldsets) This option will notify the user of both the beginning and end of a
fieldset
element.
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 legend
text:
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, fieldsets
and legends
are not announced.
Using Firefox
When using Firefox, Window Eyes does not recognize or announce the presence of the fieldset
or 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 fieldset
or legend
information is announced.
Testing Notes:
- 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.
Conclusion
The fieldset
and 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 legend
or 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.
The fieldset
and 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.
Comments
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 + F6
or 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
display
element] solve some of the rendering ambiguities within assistive technology user agents?Hi thaker,
you wrote:
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?
Faulkner–
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
fieldset
andlegend
is 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.
Hi thacker,
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.
Faulkner–
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
fieldset
andlegend
, 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