Address title attribute and name prohibited elements

[scottaohara]

This PR does a few things:

• Revises naming computation section to
  • identify elements which are name prohibited, reducing these items accName algorithm to only accept names from aria-label/aria-labelledby. Title specifically called out to contribute to description, not name. (see: Update HTML-AAM to use title for description instead of name, when the name is prohibited html-aam#552) - closes Title should not contribute to accName for generic elements html-aam#506
  • revise labelling of a and area element naming, as their href-less versions are name prohibited
  • Fix 'Sectioning and Grouping Elements' to just "Sectioning Elements' (the concept of grouping elements was removed. More changes need to happen here.
  • Removes Text-level elements naming computation section (these largely all became part of the prohibited naming section)
  • Adds new "elements which cannot be named" section (a couple of these were part of the text-level elements section, so they needed a place to go, as simply folding them into name prohibited didn't make sense, to me)
• addresses marking role=listitem as name prohibited - closes listitem can only be labeled by author and not by content #1712
• addresses the desire to make sure the title attribute does not produce redundant information (e.g., <div title=foo>foo</div> title should not return a desc. Nor should it for <button title=foo aria-label=foo>...</button> - as the title matches the content of the div, and the accName of the button)

I currently don't have header and footer listed in this update - because I really would rather not put them into the name prohibited category when they aren't banner/contentinfo landmarks, and would really just hope we can get #1931 and updating the non-landmark header and footer elements to the new proposed roles.

Test, Documentation and Implementation tracking

Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.

• "author MUST" tests:
• "user agent MUST" tests:
• Browser implementations (link to issue or commit):
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations?
• Related APG Issue/PR:
• MDN Issue/PR:

---

Preview | Diff

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	140b04e
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/66f406e13f41eb0008ac7fc3
😎 Deploy Preview	https://deploy-preview-2292--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jcsteh]

identify elements which are name prohibited, reducing these items accName algorithm to only accept names from aria-label/aria-labelledby.

So does "name prohibited" mean that aria-label and aria-labelledby are still allowed? Isn't that effectively "name from author"? And doesn't this contradict ARIA/AccName, where "name prohibited" disallows aria-label/aria-labelledby, or am I misconstruing something?

[scottaohara]

@jcsteh ARIA's name prohibited is an author must not.

The rational behind the name prohibited step added to accName is here

so the element itself (e.g., with a generic role) is now not to be given a name, but the aria-label/ledby on the element can still be used in the calculation of another element's name. (i honestly still don't understand this use case and why the button couldn't have been given an aria-label, rather than the span within it... this just seems confusing).

While there's a bit of edits to recategorize things, effectively the primary change of this PR (for the html aam spec) is only removing title from these element's accName steps.

[jcsteh]

Ah. I get it. I was misinterpreting the "Name Prohibited Elements" section as being the instructions for computing the name of a name prohibited element itself; i.e. when such an element is the root element. But if I understand you correctly, that section is also meant to be used when the name is being computed during a descendant traversal (and similar for the other elements under "Accessible Name Computations By HTML Element"). Probably just my misreading, but I wonder if anyone else might make the same mistake.

[aleventhal]

Presumably name prohibited elements are still a pass through when computing the name of ancestor.

[rahimabdi]

Where does the "autonomous custom element" link to? It doesn't link to this so unsure if it's a ReSpec issue: https://html.spec.whatwg.org/multipage/custom-elements.html#autonomous-custom-element.

[scottaohara]

that's my bad for putting the "(if ...)" into the <a>. fixing that now.

[rahimabdi]

Would it be valuable to have the list of sectioning elements here?

[scottaohara]

Yes. But this section needs to be redone, so I’d rather not do this just to undo it later