Consider allowing label elements to provide a label for landmark elements

[carmacleod]

Certain HTML elements (main, nav, aside, header, footer, section, form) can have implicit ARIA landmark semantics.

Two of these - section and form - will only have implicit ARIA landmark semantics if they have an accessible name.

1. section element will have implied landmark role "region" if it has an accessible name:

   role=region if the section element has an accessible name.

2. form element will have implied landmark role "form" if it has an accessible name:

   role=form if the form element has an accessible name.

At present, the only way to give a section or form element an accessible name is to use either the aria-label or aria-labelledby attribute.

This is a problem if a user agent wants to include section and form elements in landmark navigation. User agents shouldn't have to rely on the presence or absence of ARIA markup to determine whether or not to include an element in a new behavior.

The label element can provide an accessible name to form controls like input, select, etc.

Consider allowing it to provide an accessible name for section and form elements as well, so that these elements can participate in landmark navigation.

<label for="settings-section">Settings:</label>
<section id="settings-section"> ... </section>

<label for="contact-info-form">Contact information:</label>
<form id="contact-info-form"> ... </form>

Alternatively, consider allowing the label element to provide an accessible name for all of the landmark elements listed above. All of them are allowed to have an accessible name - it's only section and form that are required to have one in order to be considered landmarks. This would allow for something like:

<label for="site-nav">Site</label>
<nav id="site-nav"> ... </nav>

<label for="page-nav">Page</label>
<nav id="page-nav"> ... </nav>

[domenic]

I don't think reusing label in this way is a good idea, but I appreciate the concrete problem description, separate from the jump to a specific solution.

[carmacleod]

Alternate suggestions welcome and appreciated.

I suppose title could be a backup plan, as in <section title="Section name"> and <form title="Form name">, because it's covered in ACCNAME step 2D... however it's a pretty horrible way to label something. (only visible on hover, not available to sighted keyboard users, ...)

[scottaohara]

Just commenting to add a bit of info here:
Presently the only way to label these landmarks with HTML alone is using the title attribute. But quickly checking how well that actually works today, there seems to be gaps. For instance, webkit doesn't appear to use the title to name a section and thus promote it to a landmark.

FWIW, I do tend to agree that it would be nice to have a feature in HTML to allow for authors to name of landmarks that didn't rely on title (often wouldn't want the default tooltip popping up on hover, and using title for a name means it cannot be used for a description). However, I also am wary of the idea of <label> being used for that as well.

Often text within the landmark (such as a heading) would accurately serve as the landmark's name. A way to explicitly associate, say a heading with its container would be nice. But definitely something that would need an author to specifically do, not an automatic association.

edit: ah. apparently took too long to type this, as Carolyn's comment came in before mine.

[carmacleod]

Heading content as first child would be quite nice, from an author's perspective. But we'd have to make it really clear that there's magic behind the scenes, because this is really common:
<section><h2>Section name</h2> ... rest of section content ... </section>.

So I think we'd find that pages would suddenly - and probably unexpectedly - have a whole ton of new landmarks.
I really don't like the magic. (I really don't like the current aria-label[ledby] magic, either). I think creating a landmark should be a conscious author decision, not an accident of doing the right thing by giving a section a nice heading.

That said, the fact that it would be so nice is compelling. I wonder if an attribute on a first-child-heading makes any sense, i.e. <section><h2 landmark>Section name</h2> ... rest of section content ... </section>. (Just spitballing!)

Hmmm... how about an attribute on the section or form? i.e.
<section landmark><h2>Section name</h2> ... rest of section content ... </section>.

<form landmark><h2>Form name</h2> ... rest of form content ... </form>.

Then I think it would be ok for ACCNAME to use the first-child-heading of a <section landmark> or <form landmark>, and this time, the author intent is really clear.

[scottaohara]

So I think we'd find that pages would suddenly - and probably unexpectedly - have a whole ton of new landmarks.

Right. this would be very bad.

which is why, in my comment, i said:

But definitely something that would need an author to specifically do, not an automatic association.

[Yay295]

<fieldset>s use the <legend> tag for something similar. Just as another example.

<form>
  <fieldset>
    <legend>Choose your favorite monster</legend>

    <input type="radio" id="kraken" name="monster">
    <label for="kraken">Kraken</label><br/>

    <input type="radio" id="sasquatch" name="monster">
    <label for="sasquatch">Sasquatch</label><br/>

    <input type="radio" id="mothman" name="monster">
    <label for="mothman">Mothman</label>
  </fieldset>
</form>

[carmacleod]

Good point, @Yay295.
I guess there's also figcaption for figure (first or last child) and caption for table (first child). (legend needs to be first child of fieldset).

Not sure if it makes sense to go with a whole new element (<landmarkname>?) as first child of section/form, or just a new attribute on section/form that points to a heading or span that is acting as its label? Heh, or add a for attribute to headings... 😂

[domenic]

I accidentally created a duplicate of this over in #7326, which has some good discussion. Trying to synthesize the two threads and summarize what I've learned so far...

• Elements where this is important:
  • This is most important for <dialog>, which per ARIA requires an accessible name; for other such elements it's optional, albeit often helpful.
  • Other cases where this is likely to be important, by @scottaohara's reckoning, are <search> and <article>. (And maybe <nav>?)
  • It's more exceptional to want to provide an accessible name for things like <section>, <footer>, <header>, and <aside>.
  • For <section> and <form>, providing an accessible name will promote them from no-role to region and form roles.
  • A bunch of other elements can have accessible names (everything in the sections spec section; everything in the grouping content spec section; and a variety of text-level elements). It's unclear to me whether we want to prioritize a no-ARIA way of giving those elements accessible names.
• Role of <hN> elements vs. new element(s):
  • There is a proposal in Issue899 accname from heading w3c/aria#1018 to auto-compute accessible names from <hN> elements. In terms of what HTML elements merging that proposal would impact, with no ARIA involved, it would be <dialog>, <aside>, <article>, and <nav>. I'm not sure if that list is final.
  • What would remain for a new/repurposed element would be <section>, <footer>, <header>, <form>, <search>, and also the general large space of nameable elements mentioned above.
• Style of solution for the non-auto-<hN> cases, i.e. cases not handled by Issue899 accname from heading w3c/aria#1018:
  • <section landmark> would cause <hN> children to become accessible names
  • An association attribute, e.g. <section namefrom=id> or <p namefor=id>. This would essentially be a non-ARIA version of aria-labelledby=""
  • An explicit child element, either existing (candidates include <legend>, <summary>, <caption>, and maybe <title> or <label>) or new.
  • Solutions based on child elements would require updating the content model. This could feel a bit weird, especially if we decide we want to cover the "bunch of other elements" cases. E.g. we'd have to allow <legend> as a child of <ul>, <var>, etc. And probably if you want to provide an accessible name for a <var>, you don't want it inside the <var> itself.
  • These solutions are not mutually exclusive, although probably we should not do too many of them.

[zcorpan]

• An explicit child element, either existing (candidates include <legend>, <summary>, <caption>, and maybe <title> or <label>) or new.

If this is meant as a general solution:

• We can't use <title> because it parses as RAWTEXT and it's display: none.
• We can't use <caption> because, like other in-table tags, it gets dropped on the floor by the HTML parser outside of tables.
• We tried to use <legend> for <details> and <figure> back in the day, but <legend> had too much styling magic in browsers to be reusable. It still has styling magic, now in the spec: https://html.spec.whatwg.org/multipage/rendering.html#the-fieldset-and-legend-elements -- I tried to limit the magic to only the "rendered legend", precisely so that we can reuse the element for other purposes in the future. I don't think this is implemented in all engines yet, though. Only Firefox passes this test: https://wpt.fyi/results/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements/legend-sans-fieldset-display.html?label=experimental&label=master&aligned
• <label> has activation magic with form controls, which we probably don't want here?
• <summary> has a default of display: list-item which is causing problems (e.g. [css-lists] automatic start value of reversed list is affected by 'counter-increment: <counter> 0' nodes w3c/csswg-drafts#6738 ).

For specific elements though, where these elements are already used and provide for a suitable accessible name, that seems OK to me. Some already do this:

https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
https://w3c.github.io/html-aam/#fieldset-and-legend-elements
https://w3c.github.io/html-aam/#figure-and-figcaption-elements
https://w3c.github.io/html-aam/#table-element

• Solutions based on child elements would require updating the content model. This could feel a bit weird, especially if we decide we want to cover the "bunch of other elements" cases. E.g. we'd have to allow <legend> as a child of <ul>, <var>, etc. And probably if you want to provide an accessible name for a <var>, you don't want it inside the <var> itself.

This is also not always possible. In particular, <iframe> parses as RAWTEXT. namefrom=id would work for iframe though.

Also, it doesn't always make sense to give an element an accessible name at all, and ARIA now prohibits it for some roles (like paragraph): w3c/aria#1117 ; for <var> I would guess it shouldn't have an accessible name.