HTML fieldset and legend, and what disabled leaves out

Why did the shipping address never arrive?

A common order form has a “Ship to my billing address” box that switches off the shipping fields. A customer fills in the shipping address, changes their mind, ticks the box, and sends. Then the shipping address they typed is gone, and if your server expected it, the order fails or lands with an empty address. Nothing in the browser warned anyone.

The cause is <fieldset disabled>, which is the right tool for the job as long as you know exactly what it does. We built that order form, filled it in Chromium 153, Firefox 155 and WebKit 26.6, and posted it to a local copy of Formgong's form backend with the shipping fieldset on and off.

What does a disabled fieldset leave out of the request?

Everything inside it, with one exception. Disabling the fieldset disables each field in it, and disabled fields are never sent, even if they hold text. The exception is a control inside the fieldset's first <legend>, which stays enabled.

Two rows catch people out. The required street inside the disabled fieldset did not stop the form, because the browser skips disabled fields when it checks required. That is usually what you want: a switched-off section should not block anyone. But the last row shows the other side. When the same form went to an endpoint with a server-side rule that the shipping street is required, the submission was refused, because the server only sees what arrives and the street never arrived. If you switch fields off in the browser, your server has to know they may be absent and read same_as_billing=yes instead. Our article on server-side form validation explains why the server can only judge what it receives.

If you want a field locked but still sent, use readonly on the field instead. A fieldset has no readonly of its own. And the name attribute on a fieldset is only for your scripts, through form.elements; it never appears in the submission.

What does a screen reader get from fieldset and legend?

A group with a name. In Chromium's own accessibility tree, each of our fieldsets became a group named by its legend: “Your details”, “Billing address”, “Delivery time”. A screen reader announces that name when focus enters the group, so a field called “Street” is heard as the billing street or the shipping street, not just “Street” twice. That is the main reason to use a fieldset whenever two fields would otherwise share a label.

Three details came out of the test. A fieldset with no legend was still a group, but with an empty name, so it gives structure without telling anyone what the group is. A plain <div role="group" aria-labelledby> produced the same named group as a fieldset, which helps when your layout cannot use one. And the checkbox we placed inside the shipping legend became part of the group's name, “Shipping address This is a gift”. Keep the legend to the question itself.

Radio buttons are where this matters most, because each option's label is a single word like “Yes”. Our HTML radio button article shows the group and option names together, and the HTML label article covers naming the fields inside the group.

Does a form backend do anything with fieldsets?

Honestly, no. A fieldset changes what the browser sends and what a screen reader hears, and that is all. Formgong, a form backend that sends each submission to your email or Telegram, stores the fields that arrive by their names, the same as any other backend; there is no fieldset feature to switch on. The HTML form generator does put each radio and checkbox question in a fieldset whose legend is the question, but that is the same advice both competitor guides we read on 3 November 2026 give, Formspree's guide to fieldset and legend from 8 September 2025 and Static Forms' fieldset guide from 2 May 2026. Both also show the “same as billing” pattern, and Formspree's notes that disabled fields are skipped when the form is sent. What neither shows is the next step on the server, which is the one that refused our order: if you add a required check on a field that can be switched off, the check has to allow for it. In Formgong that means leaving ship_street optional under Field checks and reading a submission with same_as_billing=yes as one that ships to the billing address. The markup below does the browser half. The HTML forms docs list the fields Formgong reads.

<fieldset>
  <legend>Billing address</legend>
  <label for="bill_street">Street</label>
  <input type="text" id="bill_street" name="bill_street" autocomplete="billing street-address" required>
  <label for="bill_postcode">Postcode</label>
  <input type="text" id="bill_postcode" name="bill_postcode" autocomplete="billing postal-code" required>
</fieldset>

<label><input type="checkbox" id="same" name="same_as_billing" value="yes"> Ship to my billing address</label>

<fieldset id="shipping">
  <legend>Shipping address</legend>
  <label for="ship_street">Street</label>
  <input type="text" id="ship_street" name="ship_street" autocomplete="shipping street-address" required>
  <label for="ship_postcode">Postcode</label>
  <input type="text" id="ship_postcode" name="ship_postcode" autocomplete="shipping postal-code" required>
</fieldset>

<script>
  // Disabled fields are not sent and not checked. Your server reads
  // same_as_billing=yes and copies the billing address itself.
  const same = document.getElementById("same");
  same.addEventListener("change", () => {
    document.getElementById("shipping").disabled = same.checked;
  });
</script>

Did a fieldset behave differently for you?

If your fieldsets send or announce something other than what we measured, in another browser or a framework, write to support@formgong.com. We will run your case and add it to the table.