In each form, does each group of fields of the same nature have a legend?
A screen reader user navigates a form and encounters a radio button labeled "Ms." Their reader announces: "Ms., radio button, 1 of 2". Without a group legend, the question asked—"What is your title?"—remains silent. They must navigate the page to reconstruct context that the visual layout makes obvious at a glance.
Criterion 11.6 requires that a grouping of fields of the same nature be accompanied by an accessible name. Three approaches are valid: a <fieldset> with a <legend> (preferred native HTML method), an element with role="group" or role="radiogroup" with an aria-label or aria-labelledby, or an individual alternative where each field in the group carries a title, aria-label, aria-labelledby or aria-describedby identifying its group membership.
Concerned cases are groups of radio buttons (title, contact frequency), related checkboxes (interests, permissions), and composite fields such as a date split across three <input> elements or an IBAN broken into segments. If individual labels are insufficient to understand the question posed, a grouping with legend is required.
No legend, no context.
Un test to assess the relevance of group legends
Presence of legend on each field group
- Identify all groups of fields of the same nature in the form: radio buttons, related checkboxes, composite fields (date, phone, IBAN).
- For each group using a
<fieldset>: verify that it contains a non-empty<legend>as its first direct child. - For each group using
role="group"orrole="radiogroup": verify the presence of anaria-labeloraria-labelledbyon the grouping element. - If no grouping element is used, verify that each field in the group individually has a
title,aria-label,aria-labelledbyoraria-describedbythat indicates its group membership. - If all the above conditions are met for each identified group, the test is validated.
Examples
❌ Non-compliant : Group of radio buttons without legend
<fieldset>
<input type="radio" id="mme" name="civilite" value="mme">
<label for="mme">Ms.</label>
<input type="radio" id="m" name="civilite" value="m">
<label for="m">Mr.</label>
</fieldset>The <fieldset> is present, but the absence of <legend> deprives the user of group context. The screen reader announces "Ms., radio button" without ever mentioning the underlying question. The user does not know that they are answering a question about title.
✅ Compliant : Group of radio buttons with <legend>
<fieldset>
<legend>Title</legend>
<input type="radio" id="mme" name="civilite" value="mme">
<label for="mme">Ms.</label>
<input type="radio" id="m" name="civilite" value="m">
<label for="m">Mr.</label>
</fieldset>The <legend> provides the group name. The screen reader announces "Title, Ms., radio button, 1 of 2". The question and answer are linked without ambiguity from the first interaction.
❌ Non-compliant : ARIA group without accessible name
<div role="radiogroup">
<div>
<input type="radio" id="oui" name="accord" value="oui">
<label for="oui">Yes</label>
</div>
<div>
<input type="radio" id="non" name="accord" value="non">
<label for="non">No</label>
</div>
</div>role="radiogroup" does create a semantic group, but without aria-label or aria-labelledby, this group has no accessible name. The screen reader enters a group area without a title. "Yes" and "No" are intelligible in isolation, but the question they answer remains unknown.
✅ Compliant : ARIA group named with aria-labelledby
<p id="accord-titre">Do you accept the terms and conditions?</p>
<div role="radiogroup" aria-labelledby="accord-titre">
<div>
<input type="radio" id="oui" name="accord" value="oui">
<label for="oui">Yes</label>
</div>
<div>
<input type="radio" id="non" name="accord" value="non">
<label for="non">No</label>
</div>
</div>aria-labelledby links the group to question text already present in the DOM. The screen reader announces the full question before the options, without content duplication. This approach is useful when the introductory text is an existing paragraph on the page.
Tips and pitfalls
⚠️ Empty <legend> or hidden with display:none
A <fieldset> with an empty <legend></legend> is non-conformant, even if a visible title appears just above it in the page. Similarly, hiding the <legend> with display:none or visibility:hidden removes it from the accessibility tree. For a visually hidden but accessible legend, use a CSS class like visually-hidden, based on clip and position: absolute.
⚠️ Composite fields: the blind spot of audits
Radio button groups are often well handled in audits. Composite fields, however, regularly fall through the cracks. A date field split across three <input> elements (day, month, year) forms a group of the same nature: without <fieldset> and <legend>, a user navigating field by field does not know whether they are entering a birth date, an expiration date, or a contract start date. This is the most common error on reservation and payment forms.
💡 role="radiogroup" vs role="group"
Use role="radiogroup" only for groups of radio buttons. For any other grouping (checkboxes, composite text fields), use role="group". Some screen readers explicitly announce "group of radio buttons" with the first role, which guides the user on the type of interaction expected before they even navigate the options.
⚠️ Single checkbox: grouping is not required
A single checkbox with an explicit label ("I accept the terms and conditions of use") does not need a <fieldset>. Grouping is only required when multiple fields share a common question that individual labels cannot convey alone. An unnecessary <fieldset> burdens the experience without adding semantic value.
⚠️ Individual alternative per field: conformant, but to be avoided
The RGAA permits not using a grouping element if each field individually carries a title, aria-label, aria-labelledby or aria-describedby that identifies its group membership. A date <input> could have aria-label="Birth day" rather than a <legend>Birth Date</legend>. This approach is conformant, but <fieldset> remains more reliable, more maintainable, and better supported across browser and screen reader combinations.
Frequently asked questions
What is the difference between criterion 11.5 and criterion 11.6?
Criterion 11.5 verifies that fields of the same nature are properly grouped (existence of a <fieldset> or role="group"). Criterion 11.6 verifies that this grouping has an accessible name (presence and content of a <legend>, aria-label or aria-labelledby). A form may fail on 11.5 if no grouping exists, and on 11.6 if the grouping exists but is not named. Both criteria are distinct and evaluated separately.
How can I hide the <legend> visually without compromising RGAA compliance?
Yes, provided you use a CSS technique that hides the element visually without removing it from the accessibility tree. The Bootstrap visually-hidden class (or sr-only in other libraries) uses clip, position: absolute and overflow: hidden. However, display:none, visibility:hidden and the HTML hidden attribute remove the element for screen readers—the legend becomes inaccessible and criterion 11.6 fails.
Why is a <legend> still required even with explicit radio button labels?
As soon as a <fieldset> or role="group" is used, a legend is required. The rule is simple: if you create a group, name it. Labels like "Yes" and "No" are particularly ambiguous without context. If no formal grouping exists in the code and the labels are entirely self-sufficient, the question of a legend does not arise.
How do I audit criterion 11.6 RGAA for grouping legends in production?
In developer tools, inspect each <fieldset> and verify that its first direct child is a non-empty <legend>. For ARIA elements, search for all role="group" and role="radiogroup" attributes and check for the presence of aria-label or aria-labelledby. The CSS query fieldset:not(:has(> legend)) in the console immediately identifies groups without a legend.
What position must the <legend> occupy within a <fieldset> structure for RGAA compliance?
Yes, according to the HTML specification. The <legend> must be the first direct child of the <fieldset>. Some browsers tolerate a different position, but screen reader behavior is not guaranteed outside this position. Always place the <legend> first for maximum compatibility with assistive technologies.