可访问性和复杂性 HTML forms：如何在表单控件之间使用标题？

Question

A client needs to create quite a complex form. We use <fieldset> / <legend> to group certain elements together. But it's not enough - even if we nest them.

Think about the following:

<form>
  <fieldset>
    <legend>Your personal details</legend>

    <label>First name: <input name="first_name"></label>
    <label>Last name:  <input name="last_name"></label>

    <fieldset>
      <legend>Gender</legend>

      <label>Male:   <input type="radio" name="gender" value="male"></label>
      <label>Female: <input type="radio" name="gender" value="female"></label>
      <label>Other:  <input type="radio" name="gender" value="other"></label>
    </fieldset>
  </fieldset>
</form>

Imagine this is only a small part of a bigger form. For example, we could have a "postal address" and a "billing address". Would we need to "indent" the whole thing once more using <fieldset> / <legend> s?

<form>
  <fieldset>
    <legend>Postal address</legend>

    <fieldset>
      <legend>Your personal details</legend>
      ...

      <fieldset>
        <legend>Gender</legend>
        ...
      </fieldset>
    </fieldset>
  </fieldset>

  <fieldset>
    <legend>Billing address</legend>

    ...
  </fieldset>
</form>

Or should we rather use headings?

<form>
  <h2>Postal address</h2>

  <fieldset>
    <legend>Your personal details</legend>
    ...

    <fieldset>
      <legend>Gender</legend>
      ...
    </fieldset>
  </fieldset>

  <h2>Billing address</h2>
  ...
</form>

While it's probably valid to nest <fieldset> / <legend> s, I would not over-do it. Party because JAWS will announce the <legend> for each contained input element (in contrast to NVDA that will only announce it once, when reaching the first contained input element).

On the other hand, headings will not be announced at all by desktop screen readers when jumping between form elements using Tab / Shift-Tab . So its information will easily be missed.

What do you think about that, dear screen reader experts? Should we use aria-describedby to attach the headings to the subsequent <fieldset> ? What if there's more than one <fieldset> below that heading?

I feel there's no perfect solution here. Any suggestions, please?

Answer 1

It's perfectly valid to nest fieldset+legend, but as you ahve said, some screen readers will repeat it for each of the elements under that legend. It makes a lot of totally useless redundency.

There is certainly no perfect solution, and no normative solution on this either, but I would go for an hybrid structure. Use legend only for the deepest level, where elements are really close together such as male/female, yes/no, etc. (ie groups of radio buttons), and headings for all the rest and intermediate levels. For example:

<h2>Personal information</h2>
<fieldset>
<legend>Gender</legend>
...
</fieldset>
<fieldset>
<legend>Marital status</legend>
...
</legend>
</fieldset>
<h2>Billing address</h2>
...
<h2>Delivery address</h2>
...

Headings have a great bonus advantage, there are shortcuts keys to jump directly to them. It's especially useful when you want to modify only one or two particular fields in the whole form. You can't do this with legend.

IF you are afraid that the screen reader user miss "Personal information", "Billing address" and "Delivery address", you may use aria-labelledby refering two IDs:

    <h2 id="billingAddressHeading">Billing address</h2>
        <p><label id="streetLabel" for=street">Street: </label>
        <input type="text" aria-labelledby="streetLabel billingAddressHeading"/>
        </p>
    
    If you use two IDs like that only on the first field of the group, you make sure that the screen reader won't uselessly read the group label for each of the fields.
    Be careful to not forget to reference the label itself in aria-labelledby, because it replaces completely the `<label>`.

Note that, technically, you are also allowed to use fieldsets without legen.

As a final note, if you find the form getting too complex, it's maybe the time to think about splitting it into several smaller pages.