Conversation
this PR attempts to close #2668 As mentioned in the referenced issue, authors naming a tooltip either doesn't consistently work with current AT, or it can introduce unintended author errors where if a tooltip is named - and associated with an element via `aria-describedby`, only the name is exposed and not the longer description that a user can see. The reason this changed to name prohibited, is because by removing the 'name from author', only 'name from contents' remained.... and there is no other role in the ARIA spec that allows name from content by itself. All other similar roles are identified as name prohibited. So, while this PR initially only changes the "name from" section from listing "author and contents" to "prohibited" - i assume a note will need to be added to further describe this change and the rational behind it. it might be worth also resolving #2507 in this PR. but before I do that, I will wait for discussion on this initial PR.
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the tooltip role definition to prohibit accessible naming, changing the "Name From" characteristic from allowing "contents" and "author" to "prohibited".
- Changed the tooltip role's "Name From" value from a list containing "contents" and "author" to "prohibited"
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Added prohibited states and properties section to the table.
|
🚀 Deployed on https://deploy-preview-2670--wai-aria.netlify.app |
|
roleInfo check diff looks good: diff --git a/common/script/roleInfo.js b/common/script/roleInfo.js
index 852d7af..937e31e 100644
--- a/common/script/roleInfo.js
+++ b/common/script/roleInfo.js
@@ -7970,7 +7970,29 @@
name: "tooltip",
fragID: "tooltip",
parentRoles: ["section"],
- localprops: [],
+ localprops: [
+ {
+ is: "property",
+ name: "aria-braillelabel",
+ required: false,
+ disallowed: true,
+ deprecated: false,
+ },
+ {
+ is: "property",
+ name: "aria-label",
+ required: false,
+ disallowed: true,
+ deprecated: false,
+ },
+ {
+ is: "property",
+ name: "aria-labelledby",
+ required: false,
+ disallowed: true,
+ deprecated: false,
+ },
+ ],
},
tree: {
name: "tree", |
|
Discussed at today's editors meeting https://www.w3.org/2026/03/11-aria-editors-minutes.html#7e86 |
|
We have three approving reviews, so I believe we now need tests and bugs on browser to update whether the name/description can come from the author provided name on a tooltip within the accname algorithm. |
|
Also we should open bugs on validators. |
|
@scottaohara @smhigley Actually when I started to write a bug reports -- I realized I'm confused. Should this markup work, where the description on the button is "This button does nothing"? If so, doesn't something need to change in the accname algorithm? Because if name is prohibited on tooltip won't force the accname algorithm to skip over aria-label and just compute the name from content. |
|
@spectranaut i guess that depends on what we want to have happen here? previously when making generics name prohibited we did not immediately make changes to actually disallow or undo the naming of those generics. it was instead a change in author requirements. if, however, we want to go and fully undo / prevent the naming of tooltips, then i'd say that's beyond merely prohibiting. which i'm not opposed to, but it was beyond the original intent of this PR which was to stop telling authors they could do something which did not consistently work / was not consistently respected by AT |
|
Ok I now understand, "name: prohibited" should just cause an author error, in validators, and not effect browsers calculation of the name. And I verified in firefox and chrome -- if I replace the tooltip in the example above with any name from prohibited thing, and their is an aria-label on it, the aria-label is used. However, the first step of the acc name algorithm says:
It is says "If the root node's role prohibits naming" -- so name prohibited, according to the accname algorithm... should effect whether the browser calculates a name?? Am I missing something?? This is on today's agenda to ask:
|
|
The ARIA Working Group just discussed The full IRC log of that discussion<Zakim> agendum 6 -- -> Change tooltip to name prohibited https://github.com//pull/2670 -- taken up [from agendabot]<pkra> spectranaut_: scott could you take a look at my comment? <pkra> zakim, end meeting |
🚀 Netlify Preview:
🔄 this PR updates the following sspecs:
this PR attempts to close #2668
As mentioned in the referenced issue, authors naming a tooltip either doesn't consistently work with current AT, or it can introduce unintended author errors where if a tooltip is named - and associated with an element via
aria-describedby, only the name is exposed and not the longer description that a user can see.The reason this changed to name prohibited, is because by removing the 'name from author', only 'name from contents' remained.... and there is no other role in the ARIA spec that allows name from content by itself. All other similar roles are identified as name prohibited.
So, while this PR initially only changes the "name from" section from listing "author and contents" to "prohibited" - i assume a note will need to be added to further describe this change and the rational behind it.
it might be worth also resolving #2507 in this PR. but before I do that, I will wait for discussion on this initial PR.
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