Tooltip role should allow referencing by aria-labelledby

[carmacleod]

Currently, the tooltip role says:

Authors SHOULD ensure that elements with the role tooltip are referenced through the use of aria-describedby before or at the time the tooltip is displayed.

This doesn't allow for labelling icon buttons in a toolbar.
We should allow aria-labelledby as well as aria-describedby.

[carmacleod]

Relevant APG issues, example, and PR:

• w3c/aria-practices#1034
• w3c/aria-practices#127 (comment) (see @ZoeBijl's example with aria-labelledby)
• w3c/aria-practices#128 (comment)
• w3c/aria-practices#998

[scottaohara]

I think this is related to #979 which warrants a further discussion, but that's not slated until 1.3 but this one is 1.2?

I think making this sort of change just further muddies what a tooltip is and doesn't help clarify why the role is even useful (on the web).

[carmacleod]

Thanks for the reminder about #979, @scottaohara. I've moved it to 1.2 (@jnurthen I hope that's ok).
I will definitely keep it in mind when trying to clarify whether to choose aria-describedby or aria-labelledby when referencing a tooltip.

I think w3c/aria-practices#1014 is related as well.

This current issue (allow aria-labelledby) came up because someone submitted an APG PR for the toolbar example that added title to the tool items. We had to reject the PR because title (as you know) has accessibility problems. However, we were very sad to reject a PR from a new contributor, and welcome any changes they could make that would work. Tooltips on tool items have been around forever, and aria-labelledby of course works beautifully on icon buttons, even if the referenced element is hidden. But since the spec said to use aria-describedby for tooltips and made no mention of aria-labelledby, I opened this issue so that the PR could be resubmitted with valid and accessible code.

[scottaohara]

this is why i think #979 needs to be hashed out prior to work like this though. As the current definition states "A contextual popup that displays a description for an element."

displaying the accessible name isn't its description, and can be currently done without necessitating a tooltip role. quick n' dirty example.

i mean, the tooltip role isn't even necessary to provide the accessible description to the element... only in testing Narrator with current Edge was the role even announced, after I navigated away from the invoking element and to the revealed tooltip itself. Which, doesn't seem particularly useful to me... navigating to an element and having its accessible name exposed, and then attempting to navigate away but encountering the accessible name again.

[mcking65]

Strictly speaking, this is an author should, not a must, so our PR that uses aria-labelledby is not necessarily dependent on this issue. That said, I agree with Scott that this further muddies the waters.

[carmacleod]

I agree that tooltip role isn't currently very useful.
For what it's worth, I've taken a stab at describing our use case in #979.

[scottaohara]

Thank you both for the replies here. I plan on making some more comments in the other issue, but regarding this issue of aria-labelledby in particular, I'm curious why visually displaying the accessible name (like a "tooltip") would require it to have a role=tooltip? Being that it's not a description, but a name.

Additionally, per Matt's comments in the other issue, I think we can agree that we wouldn't want to add any unnecessary verbosity to what would otherwise be just announcing the accessible name of an element, in giving it a role of tooltip. So I'm just unsure of why, if there are already ways to produce the desired announcement of an accessible name, and expose the name visually, without using a role, we would update the spec to make an allowance for a use case that doesn't require or add benefit from the role?

[jnurthen]

Lets close this and discuss in #979