Related form inputs are missing fieldset and legend

What is this issue?

A set of related form controls (typically radio buttons sharing one name attribute, or a set of checkboxes representing a single multi-select question) is marked up as a flat list of individually-labeled inputs with no <fieldset> wrapping them and no <legend> naming what the group as a whole represents. Each option might have a perfectly good individual label (“Email,” “Phone”), but nothing programmatically connects those options to the shared question they’re answering (“Preferred contact method”).

Visually, a heading or bold text placed above the group can make the relationship obvious to a sighted reader, but headings and surrounding text have no code-level connection to the inputs beneath them the way a <legend> inside a <fieldset> does.

Why does this matter?

Radio buttons and checkboxes are almost always answers to a specific question, and that question is exactly what a <legend> is designed to announce automatically as a screen reader user moves into the group. Without it, a user tabbing through a set of radio buttons hears each option’s individual label (“Email,” then “Phone,” then “Text message”) with no indication of what question those choices are actually answering, unless they’ve retained that context from reading unrelated content earlier on the page.

This gets worse on a page with more than one similarly-structured group. Two separate radio button sets, one for “Preferred contact method” and another for “Preferred delivery time,” both using the same three-item pattern, are indistinguishable to a screen reader user navigating group by group if neither has a <legend>; both announce as an unnamed cluster of options with no way to tell which question is which.

Who is affected?

• Screen reader users: hear each individual option’s label with no shared group name, forcing them to infer the actual question being asked from context that may not be nearby or may not exist at all in the DOM.
• Cognitive disabilities: users who benefit from a clear, explicit statement of what a set of choices relates to lose that anchor when the group’s purpose is only implied visually rather than stated in a way every navigation method exposes.

What users experience

Amara uses NVDA on her Windows laptop to complete a support request form that asks how she’d like to be contacted, using three radio buttons (Email, Phone, Text message) with a bold, unstyled <div> heading above them reading “Preferred contact method” that isn’t connected to the group in any programmatic way. She tabs into the radio group and NVDA announces “Email, radio button, one of three” with no mention of what question she’s answering. She has to arrow back up through the page to find and read the disconnected heading text before she can confidently continue, a step a sighted user skips because the visual proximity already told them the same thing instantly.

How do I fix it?

Wrap the group of related inputs in a <fieldset> element and add a <legend> as its first child, naming the shared question the group answers. This works because a <legend> inside a <fieldset> is automatically announced by screen readers as part of every individual option’s context: the browser exposes this specific parent-child relationship to assistive technology without any extra ARIA needed.

Keep each option’s own <label> exactly as it was; the <legend> supplies the group’s shared name, not a replacement for each individual choice’s own label. If the visual design doesn’t want the browser’s default fieldset border and padding, that’s purely a CSS concern; you can restyle or remove the default appearance entirely while keeping the underlying semantic structure intact.

Code Examples

<div class="contact-method-heading">Preferred contact method</div>
<label><input type="radio" name="contact" value="email"> Email</label>
<label><input type="radio" name="contact" value="phone"> Phone</label>
<label><input type="radio" name="contact" value="text"> Text message</label>

<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
  <label><input type="radio" name="contact" value="text"> Text message</label>
</fieldset>

The <legend> is now programmatically part of the group, so a screen reader announces “Preferred contact method” as context when the user first tabs into any of the three radio buttons; the same information the disconnected heading was trying to convey visually, now available through every navigation method, not just reading in visual order.

Common Mistakes

Mistake: “A heading right above the group already explains what it’s for.” A heading has no code-level relationship to the form controls beneath it; it’s just text that happens to sit nearby in the visual layout. Only a <legend> inside a <fieldset> is automatically announced as part of each option’s context; a heading requires the user to have already read it and remembered it while navigating separately into the group.

Mistake: “Each radio button already has its own label, so the group is fully labeled.” Individual option labels (“Email,” “Phone”) and a group-level name (“Preferred contact method”) answer two different questions: what is this specific choice, and what question are these choices collectively answering. A group with only individual labels and no <legend> is missing the second piece entirely.

Mistake: “Fieldset styling always looks like an ugly gray box, so I’ll skip the element entirely instead of restyling it.” The default browser appearance of <fieldset> and <legend> is just CSS, fully overridable without touching the underlying semantics; removing the element to avoid the default look also removes the accessibility benefit it provides, when the actual fix is a few lines of CSS resetting border and padding.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. This rule id has no automated detector, no manual-check workflow, and no entry in RedFlag’s coverage model today; it exists purely as documentation for a check the product doesn’t yet track in any form. There is no DOM query, AI review, or guided walkthrough running against this pattern.

False negative: every case, since nothing is checked automatically: RedFlag will not surface a missing fieldset/legend on its own regardless of how many ungrouped radio or checkbox sets a page has. False positive: not applicable, since no automated flag is ever raised for this rule. Manual step: the Manual Testing steps below are, for now, the only way to catch this issue; treat every radio button or checkbox group on a form as a candidate to check by hand.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Identify any set of radio buttons or checkboxes on the page that answer a single question together.
3. Tab into the first option in the group and listen for a group name announced alongside the option (“Preferred contact method, Email, radio button, one of three”).
4. If NVDA or VoiceOver announces only the individual option with no group context, inspect the markup to confirm whether a <fieldset> and <legend> are present and correctly wrapping the group.

Related WCAG Success Criteria

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation must also be available programmatically. A visually-grouped set of inputs with no <fieldset>/<legend> is exactly this failure: the grouping relationship is obvious on screen but absent from the code.

Related Issues

Form input has no label covers the individual-field naming requirement this rule builds on top of: a fieldset names the group, but each option inside it still needs its own label too.

Input only uses placeholder as its label is a related individual-field labeling gap that commonly appears on the same forms as ungrouped radio and checkbox sets.

Form field has more than one label covers a different labeling defect on the individual-field level, distinct from this rule’s group-level naming gap.

Form field autocomplete attribute is missing or invalid is a separate purpose-identification requirement that can affect the same forms, particularly grouped address or contact-method fields.

Form error is not clearly identified matters even more for grouped inputs, since an error on an entire radio group needs to be associated with the group as a whole, not just one option inside it.

References

• W3C Understanding 1.3.1: Info and Relationships
• W3C Technique H71: Providing a description for groups of form controls using fieldset and legend elements
• MDN: The Fieldset element