HTML5 Form Semantics: fieldset, legend, label, and optgroup

In 2015, I answered a question on Stack Overflow in Portuguese explaining four HTML form elements that most developers ignored: <fieldset>, <legend>, <label>, and <optgroup>. These tags had been in HTML for years, but the majority of forms I saw in the wild used <div> for everything.

The 2015 Answer: What These Tags Actually Do

<label> — Extends the Click Target

The most practical one. A <label> associates text with a form control. Click the label, and the input gets focus:

<!-- Click "Email" to focus the input -->
<label for="email">Email</label>
<input type="email" id="email" />

<!-- Or wrap the input -->
<label>
  Email
  <input type="email" />
</label>

Without <label>, users have to click the tiny input box itself. With it, the entire text becomes clickable. On mobile, this difference is huge.

<fieldset> and <legend> — Group Related Fields

<fieldset>
  <legend>Shipping Address</legend>
  <label>Street <input type="text" name="street" /></label>
  <label>City <input type="text" name="city" /></label>
  <label>ZIP <input type="text" name="zip" /></label>
</fieldset>

<fieldset> draws a visual border around related fields. <legend> provides the group title. Most developers skipped these because the default browser styling looked dated — a raised border with the legend text interrupting it.

<optgroup> — Group Select Options

<select name="car">
  <optgroup label="Swedish Cars">
    <option>Volvo</option>
    <option>Saab</option>
  </optgroup>
  <optgroup label="German Cars">
    <option>Mercedes</option>
    <option>BMW</option>
  </optgroup>
</select>

Groups options in a dropdown with bold, non-selectable headers. Simple, useful, and rarely used.

Why Developers Skipped Them

In 2015, the reasons were mostly cosmetic:

• <fieldset> had ugly default borders that were hard to override
• <legend> positioning was quirky across browsers
• <label> “worked” without the for attribute (it just didn’t associate with the input)
• <optgroup> couldn’t be styled much

Developers reached for <div class="form-group"> instead and styled everything manually. It looked better. It worked for sighted mouse users. And that was enough — in 2015.

The 2026 Reality: Accessibility Made These Mandatory

WCAG compliance isn’t optional anymore. Accessibility lawsuits, government requirements, and the EU Accessibility Act have made semantic forms a business requirement. And these four elements are at the foundation.

Screen Readers Need fieldset + legend

When a screen reader encounters a group of radio buttons without <fieldset>:

“Radio button: Yes” — Yes to what?

With <fieldset> and <legend>:

“Subscribe to newsletter group. Radio button: Yes”

The <legend> provides context that screen readers announce before each field in the group. Without it, radio buttons and checkboxes lose their meaning.

label Is Non-Negotiable

Every input needs a <label>. Period. Automated accessibility tools flag unlabeled inputs as errors. Placeholder text is not a substitute — it disappears when the user types, leaving no visible label.

<!-- Fails WCAG -->
<input type="email" placeholder="Email" />

<!-- Passes WCAG -->
<label for="email">Email</label>
<input type="email" id="email" />

CSS Caught Up

The styling limitations that pushed developers away from semantic form elements are gone. Modern CSS handles <fieldset> and <legend> gracefully:

fieldset {
  border: 1px solid #333;
  border-radius: 8px;
  padding: 1.5rem;
}

legend {
  font-weight: 600;
  padding: 0 0.5rem;
}

No hacks, no workarounds. The elements are fully styleable in every modern browser.

Key Takeaway

In 2015, these form elements felt like relics — poorly styled tags from an older web. In 2026, they’re the foundation of accessible forms. <label> extends click targets and provides screen reader context. <fieldset> and <legend> group related fields in a way screen readers can announce. <optgroup> organizes long dropdowns.

Skip them and your form might look fine — but it won’t work for everyone.