-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address title attribute and name prohibited elements #2292
base: main
Are you sure you want to change the base?
Conversation
This PR does a few things: which i will list in a bit...
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
clarify that uas not use the title attribute for a description if the value of the title matches the element's accessible name, or the the content of the element (subtree)
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 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. |
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. |
Presumably name prohibited elements are still a pass through when computing the name of ancestor. |
@@ -16309,7 +16309,7 @@ <h4>`iframe` Element Accessible Name Computation</h4> | |||
</p> | |||
</section> | |||
<section> | |||
<h4>Section and Grouping Element Accessible Name Computation</h4> | |||
<h4>Sectioning Content Elements Accessible Name Computation</h4> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be valuable to have the list of sectioning elements here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. But this section needs to be redone, so I’d rather not do this just to undo it later
This PR does a few things:
a
andarea
element naming, as theirhref
-less versions are name prohibited<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
andfooter
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.
Preview | Diff