The <fieldset> is a useful tool for organizing and grouping related items within a <form,> and has been used for a long time in desktop applications. When it’s combined with the <legend< (which is contained inside the <fieldset>, and is a required element if you use the <fieldset>), it has the effect of creating a box around the grouped items and showing a description to the right of each item.
The fieldset attribute is used to logically group data items that share some characteristics. For example, you may wrap a fieldset around personal details, and another around work details, when capturing information about a visitor in an application form.
The <fieldset> element adds structure to >form<s by grouping together related controls and labels.
Best practice: Grouping together related controls can improve tabbing navigation and make >form<s easier to process for users of assistive technologies.
The <fieldset> tag should encompass complete sections of a complex >form< [A U], and may encompass the whole of a simple >form<.
The <fieldset> tag is used to logically group together elements in a <form>.
The <fieldset> tag draws a box around the related <form> elements.
The <legend> tag defines a caption for the <fieldset> element.
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.
The <fieldset> and <legend> elements are a useful part of a web developer’s toolkit for making <form>s 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 (l<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 <form>s 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 <fieldset>s 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.