Allow headings within label elements

[36degrees]

Update the spec to permit headings as part of the <label> element’s content model.

In #724 the spec was changed to allow headings as permitted children of legends, but this same change was not also extended to labels. This meant that including a heading as part of a legend is valid, but including a heading as part of a label is not.

This led to an inconsistent experience when building interfaces where the label for a form field or fieldset is also the heading for the page – with a fieldset, the heading could be nested inside the legend, but with a single field the label instead needed to be nested inside the heading. Unifying the behaviour of the two elements so that both permit headings reduces the complexity for the developer.

Fixes #1270.

[36degrees]

I've linked my W3C and GitHub accounts, so if you're able to 'revalidate' the ipr check I think it will pass.

[edent]

As I work with @36degrees, I recuse myself from reviewing and merging responsibilities :-)

[scottaohara]

Hi @36degrees

While your test cases indicate there is no issues for screen readers interpreting this isolated pattern (thank you again for the detail you went into with those), this PR doesn't yet address how this change might affect the semantics of the label element in contexts beyond the presented use case.

A few points to consider:

• As specifically called out in the spec, Phrasing content, as a label is categorized, does not allow for child Flow content elements (which headings fall under). Exceptions to this rule are for the few Phrasing content elements that have a transparent content model. There would need to be reasoning, and examples added, to explain a label should be treated as an exception and allowing heading child elements, while also still not being classified as having a transparent content model. If labels were to be reclassified as transparent, that opens up many more questions that we'd need to test and work through.

• I'm finding it difficult to understand how this change would benefit authors on a larger scale. Outside of the context that was presented, I would find it odd to have a label and heading combined in this proposed manner. One reason is that a label as the parent of a heading would indicate to me that the label is the primary semantic element and the heading is subservient to that. This seems at odds to the accepted semantics of these elements. e.g. a label captions a single form element, where a heading gives context to a group of content.

Additional examples and notes may need to be outlined to indicate to authors how they should expect this sort of pattern to be interpreted by user agents (browser and screen readers)

For example...

• The browser/screen reader tests you performed and submitted were great in looking at a single heading within a label and determining that there would be no adverse effects to the form control announcements in your examples, but I think it would be useful to look at other combinations of allowed child elements. Consider the following:

  <label for="idref">
    <h3>Contact Information</h3>
    User Name
  </label>
  

  As with your findings, this is announced as a single string when focusing the labelled input. However as the element contains text nodes and a heading, screen readers will announce the these separately when in reader mode or when navigating by the virtual cursor. This is not necessarily unexpected for one that understands how navigating with a screen reader works, but may be a cause for confusion for some users as to why the announced name of an input is conveyed one way, when in forms mode, but in another way when interacting with the label's contents via other means. Why is the heading that they navigated to also repeated when they tab into the first form control?

• This change makes no indication that headings nested within labels can still be invalid. For example, there are many instances where authors wrap labels and form controls within p elements, both in and outside the context of a parent form. Without further clarification as to when headings are allowed in labels or not, one might think the following would pose no issue:

  <p>
    Here's a test
    <label><h3>of nested content</h3></label>
    inside a paragraph.
  </p>
  

  However when a browser is done parsing the above markup, it is render as:

  <p>
    Here's a test
    <label></label>
  </p>
  <h3>of nested content</h3>
  inside a paragraph.
  <p></p>
  

To wrap up...

This seemingly minor change will increase the complexity of appropriate usage of labels, not decrease it.

To more directly answer your question about why this was an appropriate change for legend, but not done so for label: In modifying the legend element to allow headings as child elements, many of these considerations and additional updates to the specification did not need to occur, because legends serve a different role than labels. A legend provides a caption to a grouping of form controls (similar to how a heading provides context to a section of content), and a legend is only allowed within the context of being the first child of a fieldset. There's no other use cases to consider.

labels have a much wider range of usage, and are currently only meant to caption a single form control. Unlike labels being categorized as Phrasing content, which factors into the rules for its content model, a legend is not defined by a content category, so there were no rules in place that would contradict the loosening of its accepted content model. Allowing headings as child elements of legend strengthen the semantics of the pairing, while in regards to label, it muddies the semantics.

Due to the issues I've outlined I do not think this change should be accepted without much more consideration and tests that provide evidence this is a needed change beyond this specific use case.

Thank you

[36degrees]

Hi Scott,

Thanks for taking the time to consider this and for putting together such a comprehensive reply. You make some excellent points – so off the back of your recommendation I'll close this and we'll explore other ways to make this work for us.

Ollie