Fieldsets, Legends and Screen Readers

Posted on Thursday, 22 November 2007 by Steve Faulkner

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 a fieldset. The legend improves accessibility when the fieldset 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
  • In Internet Explorer the fieldset is displayed with a solid border and the legend text is overlayed on the top left border. fieldset with a legend of 'filter by', containing 3 radio buttons labeled television,radio and cinema
  • In firefox the fieldset is displayed with a solid border and the legend text is overlayed on the top left border
  • In Opera the fieldset is displayed with a solid border and the legend text is overlayed on the top left border

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, the LEGEND element might identify a FIELDSET 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 the LABEL.

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.

 


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

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

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

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

  4. 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?

  5. Hi thaker,
    you wrote:

    Maybe I am missing something [which is a very real possibility]

    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?

  6. 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 and legend 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.

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

  8. 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 and 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.

Comments for this post are closed.

Sarah Horton’s approach fit into the style of the organization so well…kudos to TPG for having UX in the mix in such a valuable way.

Becky Reed, Sr. Director User Experience, Healthwise