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.

[jimmyfrasche]

If, for the sake of having something tangible to use in examples, <name> is chosen would

<nav>
  <name hidden>the accessible name</name>
  [...]
</nav>

work even though it's hidden? (I agree that it's always better to have a visible name but I don't always win that argument and would love a simple way to sneak accessibility in without aria and ids)

As long as this is being solved once and for all, it would also be great if whatever the solution ends up as worked in all the other cases and you could use, say, <name> instead of a <caption> and it had whatever local magic is needed so that you could just tell everyone "look, just use <name>, ignore all those other tags, they're deprecated". I'm sure there are good reasons why that can't be the case but I can dream.

[aardrian]

@scottaohara responded to Domenic's questions in the now-closed issue, (before it was closed) which I am pasting here:

To sort of quickly go over some of your points:

• I believe you do have a good understanding of the problem - naming HTML elements which have implicit ARIA roles that allow for naming from author presently requires authors use ARIA, or the title attribute (though as I mentioned in the other thread, title may not always work - though that is / was a bug. I'd need to reverify).
• The necessity of the mentioned elements to always have an accessible name will vary. For instance, ARIA requires a dialog have an accessible name, but then other roles (and thus their HTML elements) like nav, main, banner (header) do not require an accessible name. When there are multiple instances of these elements/roles on a page, the need for providing accessible names can increase. e.g., two search, navigation or complementary landmarks.
• A section for instance, we would not want to have authors add accessible names to unless they specifically want those sections to be promoted to role=region landmarks. Too many landmarks on a page can dilute their usefulness. Similar for header and footer. Similar issues would arise from auto-naming footer, header, aside.
• Where automatic naming from the first heading would be helpful, per the issue that @jnurthen provided, imo, would be dialog, search and article. (Note: this is purposefully different from the roles in the linked ARIA PR, as in those cases authors would be specifically defining the roles of the elements, but in HTML the roles of some elements are contingent to their location in the DOM (scoped to body, or main, for instance), and we wouldn't want a bunch of new landmarks popping up in places they shouldn't be. E.g., a header, containing a heading, within a section within an article - we would not want that to become a named role=banner.
• Another thing to consider, there are other elements in ARIA / HTML which can be named from authors when situations arise where it might be helpful to do so. For instance, <ul> can be given a name. But, we would not necessarily want authors to start adding headings as descendants of lists or their list items.

FWIW, and this is specifically my own personal opinion, I am very much in favor of HTML adding an alternative mechanism beyond title to name elements which have implicit ARIA roles which allow for naming from authors. I would be very happy to see automatic naming from headings for elements like dialog and article. For other nameable elements, I would tend to lean more towards an explicit association with an element. For instance:

<!-- the following are not formal attribute name proposals -->
<section namefrom=id> 
  <h# id=id>My heading and name</h#>
  ...
</section>

<!-- or -->
<p  namefor=foo>Groceries</p>
<ul id=foo>...</ul>

If there is a new element to specifically allow for naming, that would also make sure that elements that don't always need names wouldn't be automatically named from their headings. I just don't have a good idea how that'd help out other HTML elements, per my list example, where the new HTML element wouldn't necessarily make sense as a child of the list. At least, not without updating the content model.

I know that OpenUI has been kicking around the idea of <tooltip>, so I would want to check in on that more before talking about what to do with descriptions. But at a high level, I'd personally also want a way to associate content (elements) with each other.

I am very interested in other people's thoughts on this subject.

[zcorpan]

@jimmyfrasche the current accessible name computation algorithm (and for HTML) doesn't care about the hidden attribute, and includes display: none elements in the accessible name if it was referenced by aria-labelledby or "directly referenced by a native host language text alternative element (e.g. label in HTML) or attribute".

One element type is not going to be able to cover all cases. For example, <table> is not able to have a new element as a child due to the HTML parser rules (it would be foster parented).

[Yay295]

What about using the alt attribute like on images?

[scottaohara]

i like the idea of having a new naming attribute that doesn't produce a tooltip like title does. but, my preference would be an element that would auto name its closest nameable ancestor, or attributes to create an association like aria-labelledby. Visible labels/names are typically far preferable.