aria icon indicating copy to clipboard operation
aria copied to clipboard

Address title attribute and name prohibited elements

Open scottaohara opened this issue 1 year ago • 6 comments

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: https://github.com/w3c/html-aam/issues/552) - closes https://github.com/w3c/html-aam/issues/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 #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 https://github.com/w3c/aria/pull/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

scottaohara avatar Jul 24 '24 20:07 scottaohara

Deploy Preview for wai-aria ready!

Name Link
Latest commit 8d60b7979bd02c918b8e8a72d81669742af76e45
Latest deploy log https://app.netlify.com/projects/wai-aria/deploys/68bea2420ed44b00083a4c02
Deploy Preview https://deploy-preview-2292--wai-aria.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

netlify[bot] avatar Jul 24 '24 20:07 netlify[bot]

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?

jcsteh avatar Sep 10 '24 07:09 jcsteh

@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.

scottaohara avatar Sep 10 '24 14:09 scottaohara

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.

jcsteh avatar Sep 13 '24 03:09 jcsteh

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

aleventhal avatar Sep 13 '24 14:09 aleventhal

@scottaohara rebased on main.

pkra avatar Mar 07 '25 17:03 pkra