- 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.
<legend>s 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>.
Defines a caption for a <fieldset>. The element must appear directly after the opening <fieldset> tag.
The <legend> tag defines a caption for the <fieldset> element.
The <legend> is used to provide the caption text for grouped form controls and text contained in a <fieldset>. By default, the text appears on the left, over the boxed outline that the fieldset creates.
No other content may appear between the opening <fieldset> tag and the opening <legend> tag—only whitespace is allowed.
Use this element to give a name to the grouped <form> elements. There are no hard rules about what goes inside the <legend> and </legend> tags, but take care: some browsers have a hard time applying styles to the <legend>, so it’s good practice to keep the text content as succinct as possible, in order to avoid styling problems. Another reason to keep the text short is that this is best for screen reader users who may have to listen to the announcement of the <legend> text before every form <input> inside the <fieldset> related to the <legend>.
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.