To me, a sensible approach would be to specify role="tooltip" as one of those magic roles that acts as a live region - that user agents should expose it when it appears, ideally. And remove the suggestion to explicitly tie it via aria-describedby. Because yes, as @scottaohara notes, it seems that the role currently has no discernible effect on its own.

My expectation would be that at least "tooltip" is announced before its content is spoken to distinguish this information from any other associated text node text. But ARIA does not define screen reader speech output. It is all in the mercy of AT. Making this a live region won't change that.

Making this a live region won't change that.

no but it would remove the need to the also tie it via aria-describedby, and perhaps make it more in line with what authors may expect...

If so you need additional JS code to update the region of control focus, otherwise you get no speech output, which is unnecessary in case of an existing relation.

As you'd likely already use JS code to show/hide the tooltip, I'm not sure this would be such an extra additional ask?

You don't need JS to show the tooltip, see tons of examples here

While CSS can be used to show the tooltip, JS will still be necessary, especially per WCAG 1.4.13.

Thanks for the hint.

WCAG 1.4.13. is new in WCAG 2.1. It has even not yet Failure examples as part of the "Failures" section (and still recommends "@@ CSS: Using hover and focus pseudo classes" as "sufficient technique which is strange).

Expect delays in adaption. Many implementations are still on WCAG 2.0.

I agree that in JS-based HTML frameworks we have always a great amount of JS control code that can be extended for such purposes. But I still doubt that adding a new live region to the page decoupled from the visual tooltip presentation will do the job. When used (as a concept extension) one day with interactive subcontent (like links) I see it more as a variant of the dialog role. It s not uncommon that tooltips are used this way and ARIA has to evolve in this direction.

Your idea also implies that devs should designate always a certain page area for "tooltip announcements" (the other option, having each control its own live region tooltip area is ridiculous, as you know since UI will be swamped with those areas). Given that, it seems that jQuery has already an implementation using a extra live region PER CONTROL.

Having just one region for tooltip updates could also have disadvantages, like a HTML code-wise decoupling of control with its very help description text which may have implications on check tools and automation in general.

I am also sure this topic should be discussed more listing pros and cons from a rational and independent perspective.

a rational and independent perspective

because clearly we don't have that? ;)

Anyway, back to the original issue: what's the point of role="tooltip" in practice if it has no effect? Should AT announce the fact something's a tooltip when it's announced? Should they do it automagically or not?

My expectation would be that at least "tooltip" is announced before its content is spoken to distinguish this information from any other associated text node text. But ARIA does not define screen reader speech output. It is all in the mercy of AT. Making this a live region won't change that.

@stes-acc commented:

Expect delays in adaption. Many implementations are still on WCAG 2.0.

Which brings me back to a topic I've brought up before... testing ARIA implementations in the accessibility APIs is not enough. It satisfies the letter of the W3C's requirement for at least two independent implementations of every feature, but it doesn't follow the spirit (which is intended to give developers confidence that features are production ready in at least two agents).

When people see that an ARIA feature has made it to Recommendation, they assume it works in the real-world. Yet time and again we find cases where an ARIA role or attribute has only one screen reader implementation, or quite possibly none at all.

Anyway, I digress, but I do think this is an important topic.

@LJWatson This is off topic for this issue but I'll note the following:

1. For future features in ARIA 1.2 and later the https://www.w3.org/WAI/ARIA/workflow states for an ARIA feature to be ready it needs "Positive confirmation of acceptance by multiple assistive technology vendors in the form of implementing support, or a comment in a public issue tracker that they intend to implement support."

2. For already shipped features the https://github.com/w3c/aria-at project is intended to provide guidance as to how well a feature is supported.

I'd like to describe our tooltip use case... to make sure that it is not left out, and hopefully, to improve it. :)

We have a code editor, and a bunch of "command buttons" (some have icons, some have text; some are in toolbars, some are not).

The code editor uses tooltips in many ways. For example, if editing javascript, there are tooltips for:

• showing a comment (if any) for the class/method/variable/etc at the current [hover/caret] position
• describing annotations for the current line, such as compiler error/warning/info, bookmark, breakpoint, etc

The "command buttons" have a tooltip that may consist of just their name (i.e. for icons), or may be a sentence or two describing the function of the button (i.e. for more complicated commands).

Designers and users have made it clear that automatically popping up a tooltip in the editor every time the text caret moves into a class/method/variable or annotated line is terrible UX (very "in your face", obscures code, "too much information I don't need right now", etc).

Further, our users (who are developers - a picky and demanding lot 😉) don't like having button tooltips pop up automatically on focus. They find it startling and annoying.

So our solution was to make all tooltips only available "on demand". Either hovering over "a thing with a tooltip" or typing Shift+F1 on "a focused thing with a tooltip" will open the related tooltip.
In addition, we have shortcut keys to go to the next/previous annotation in the editor. Those move the caret to the next annotated word or line and pop up its related tooltip immediately.

Our editor actually only implements one "tooltip element", which it populates and positions as needed, to give the illusion of many tooltips. This "tooltip element" has aria-live="assertive" so that AT read it when it's populated and shown (i.e. invoked by keyboard or mouse). It doesn't currently use role="tooltip" or aria-describedby.

Our button tooltips don't have aria-live. They are created, positioned and displayed on hover or Shift+F1. They have role="tooltip", and the button references them either with aria-labelledby (if the button needs a name), or aria-describedby (if the button already has a name, and the tooltip content is a sentence or two with more detail than just a name).

The tooltips that provide a name are there for sighted users to make sense of an icon. Referencing name tooltips with aria-labelledby ensures that the same name is used for screen reader users.

@scottaohara I've never noticed the problem you mentioned in #987 (comment):

navigating to an element and having its accessible name exposed, and then attempting to navigate away but encountering the accessible name again.

because a screen reader user wouldn't bother opening a button's tooltip when they already know its name.

So, to the point of this issue, one possible use for role=tooltip could be to improve the "tooltip on demand" use case. AT could look at whether an element's aria-describedby points to an element with role=tooltip, and if so:

• don't automatically read the aria description
• play a small tone so that users would know there's a descriptive tooltip available (I think it would be too verbose to say "has tooltip")

Then users could choose whether or not to open the tooltip to hear the description.

Getting AT to buy into this would be hard, though, because so few apps (possibly only one? 😄) have on-demand tooltips.

A relationship between a tooltip and the element it complements seems necessary to me because:

1. As a user, coaxing a screen reader to repeat ephemeral live announcements is difficult.
2. If the content of a tooltip could be focused by a reading or touch cursor, the AT would not be able to provide a function that indicates which element it complements.

For elements such as graphical buttons or interactive icons, the tooltip provided for the visual interface is often redundant when compared to the accessible name. While the tooltip may not be worded in exactly the same way as the accessible name, it may not provide any additional useful information. Thus, authors need a way of providing those tooltips without adding undesirable verbosity.

As for how a tooltip is announced, that seems like a screen reader design decision. I don't see a benefit to hearing the word tooltip first. Besides being a techy term that is likely meaningless to a non-developer, its content and the timing of its announcement seem like adequate distinction from other attributes that are currently announced automatically.

It might be useful to make a list of the most common uses of tooltips. Then for each, list the use cases that an assistive technology user may have for perceiving the tooltip content.

Common uses might include:

1. Providing information relevant to all users that supplements the visually persistent UI.
2. Providing modality-specific help or instructions for an element, e.g., help relevant only to mouse users, help relevant to only keyboard users, etc.
3. Providing a text name for a graphical element.
4. Providing a text description of a graphical element.

For each of the above, beneficial assistive technology behaviors could be quite different. If the tooltip is relevant only to mouse users, there are not likely many or any assistive technologies that would want to bother their users with it. On the other hand, if a tooltip is providing keyboard shortcut instructions, it would be particularly relevant to assistive technology users. Similarly, if a tooltip is providing an accessible name, it would be especially important, but you would not want the same behavior as the keyboard shortcut description.

Thank you for responding with your use case @carmacleod, there's a lot here that I think could really help in suggestions to make this role more useful. Additionally, I also think that Matt raises many good points in that further exposing a tooltip could be useful, but could also be completely unnecessary in some situations. If anything, both of your replies make me think it's even more important to narrow down when a role=tooltip should be used (e.g. for descriptions), and better indicate that the role should not be used when not necessary, so as to not create unnecessary verbosity, or functionality that is not useful for certain types of content.

A few notes per specific quotes:

So our solution was to make all tooltips only available "on demand".

I think this would be a wonderful solution for tooltips, e.g. native title attributes or ARIA tooltips. Let people know there was more information, but not announce it by default. It'd allow them to be available but not have to be revealed immediately, and thus hopefully less annoying. One of the reasons we even need "toggle tips" is due to the current expectation that a tooltip must be shown on hover/focus. If there were a command / visual cue to announce/show the tooltip when actually desired, this could even help reduce the need for toggle tip patterns.

Either hovering over "a thing with a tooltip" or typing Shift+F1 on "a focused thing with a tooltip" will open the related tooltip.

Again, some sort of "screen readers MAY/SHOULD let users know there is a tooltip associated with this element" would definitely promote this from a largely (presently) unannounced role to something that could create benefit, and would be in line with Matt's comment "A relationship between a tooltip and the element it complements seems necessary..." I agree with this fully, otherwise why use the role?

The tooltips that provide a name are there for sighted users to make sense of an icon. Referencing name tooltips with aria-labelledby ensures that the same name is used for screen reader users.

But the `role="tooltip" doesn't really do anything, right? It's not a description to the element. The role is not announced, nor would you want it to if it's just providing the accessible name. It's just using a role for the sake of the role and because it shares a similar visual design to a descriptive tooltip? Or am I missing something?

I've never noticed the problem you mentioned in #987... because a screen reader user wouldn't bother opening a button's tooltip when they already know its name.

It reads to me that your comment is reliant that there is a mechanism in place to let the user know a tooltip can be made available via activation (e.g. per your particular use case and how its been implemented). Under the current ARIA definition for a tooltip though, web developers are given the instructions should appear on hover/focus of an element, and while that may not always be triggered when navigating by virtual cursor, there are instances where it could. For instance, VoiceOver on macOS is but one example of where a tooltip could be navigated to after it was announced in context to the element it is associated with:

To help mitigate against situations like this, I've often added an aria-hidden="true" to the exposed tooltip or accessible name, so that it isn't discoverable or announced beyond the context it was intended. But then, aria-hidden="true" added to a role=tooltip again begs the question, "why even use the role if its just going to be hidden?"

to the point of this issue, one possible use for role=tooltip could be to improve the "tooltip on demand" use case... Then users could choose whether or not to open the tooltip to hear the description.

Again, I'd be very much in favor of this, emphasis on description. I think where this gets murky though is adding the complexity that a tooltip can be a representation of an accessible name, on top of the current expectation that it is a description.

Per Matt's comment after outlining four use cases for a "tooltip" and "tooltip-like" UI element:

For each of the above, beneficial assistive technology behaviors could be quite different... Similarly, if a tooltip is providing an accessible name, it would be especially important, but you would not want the same behavior as the keyboard shortcut description.

Regarding my comments in the other issue, revealing an accessible name for an element in a manner that a designer might describe as a "tooltip", doesn't mean it actually needs to be coded as one, nor would it be always useful for someone to have it announced as one.

I think the use case you provided is a solid one for how tooltip could be revised to be more useful. I also think Matt's comments show that expanding role=tooltip to be used for things that aren't descriptions adds complexity to a role where then AT would need to figure out "is this a description, if so, do something useful. VS is this an accessible name, if so, maybe don't do anything?"

Ok, I think that's all I got to say about this right now? I hope this was helpful. Again thank you.

It would be super cool if someone can summarize SHORTLY

• why tooltip role was invented at all
• how the conflict with 1.4.13 was handled
• what screen readers actually DO when tooltip role was found

BTW I agree that speaking "tooltip" would be ony of benefit when such a thing would be found present in DOM while virtual reading. I never insisted on in speaking it when shown on control focus.
If this situation never occurs since everybody is hiding it using aria-hidden than fine with me.

• don't know. personally, rather wish it hadn't been (at least based on current behavior-lack there of).
• the role came into being before 1.4.13, so something that needs to be thought about now as opposed to then.
• from last time i tested, largely nothing. a few instances of actually saying the role if the element that had it received virtual cursor focus. but not at all announced otherwise (e.g., when the element that invokes the tooltip is focused and the aria-describedby content is read aloud).

As a corporate developer I can tell you fundamentally there are two different tooltips. The polite version and the non-polite version.
A polite version is something that a user would hover or be alerted to, but not really change the DOM structure ahead of the user, nor direct them. The non-polite version is one that takes the user and places them inside of an instantiated modal of some sort that the user then has to navigate out of to resume browsing their previous node level.

I feel like the non-polite version of a tooltip is generally just an anti-pattern. If your tooltip requires a close button, you are trying way too hard to be useful to the user. In the case of a non-polite tooltip, labeledby and label both work fine, as does some implementations of an alert role. Remember, this is supposed to be a tip, not a trap.

For polite tootlips, role="tooltip" is redundant. Even if it were read in some manner, the alert role can accommodate all of this functionality with better context inside of the element with the role.

Creating functionality for the non-polite version of a tooltip just promotes the anti-pattern in my opinion.

I‘d like to point the fact of the HOVER state which is not possible in touch screens (mobiles). What is wrong if we print a text-hint for sighted people, and additionally, another text-hint but longer, more explanatory, with an ID, which will be tied to “aria-describedby”? Having the text-hint rendered already can save time on making additional clicks just to trigger something that should be announced prior to decrease errors. I am talking about web forms.
Here is my example, opinions, please:
https://codepen.io/limakid/pen/YzQxoNG?editors=1100

I wonder, how much the text-hints can decrease a lot the wrong using of the forms and avoid the error messages.

speaking with @aleventhal today, it's generally assumed that a tooltip should not allow for interactive children. The spec doesn't say one way or the other, but this is something that authors do. Would adding clarity on this in the spec be useful. If users could enter a tooltip because there was a focusable element within, then that actually would make the role useful as it could then be announced by the AT

Back when we added role=tooltip, the assumption was that role=tooltip could allow interactive content.
It's a common authoring pattern. How else would authors express it?

so more of a popup / mini-dialog, rather than what's traditionally a "tooltip" (in the "you hover the mouse over something, and it gives you a hint/tip on what that thing is" sense)...

@patrickhlauke yes, but is generally triggered on focus or hover.

@patrickhlauke A more tooltippy use case is some text followed by a link "Learn more".

Aaron's use case is so incredibly common, and the advise to not allow/do this generally results in needing a complete re-implementation as either a "toggle tip" or "make that tooltip content (or at least the link) persistently available in the document.

in many cases, especially with complex content shoved in a tooltip, that's generally what the solution should be. but in simpler usage, it does seem a bit draconian (i use that term and am directly thinking of my past self who was previously not as open to this idea).

#2002 related on F2F agenda