Tooltips are presentational

The ARIA tooltip role is functionally useless and semantically meaningless. The only legitimate use-case for tooltips is to show information that’s already accessibly defined. So tooltips only benefit sighted users, and are therefore presentational.

That’s my conclusion, and here’s how I arrived at it.

What are tooltips?

Sarah Higley discusses the history and purpose of tooltips in her article Tooltips in the time of WCAG 2.1. I won’t paraphrase, but it’s fair to say that tooltips are (and were designed to be) an aspect of visual interface design, triggered by mouse hover, to provide information that users can see. The concept doesn’t include keyboard and non-sighted users.

Although that in itself doesn’t preclude an underlying meaning. The interactions of drag and drop are also inherently visual, yet they can still be represented by non-visual semantics. Can we do the same with tooltips?

The ARIA tooltip role

ARIA includes a tooltip role which is specified as follows:

A contextual popup that displays a description for an element.

The tooltip typically becomes visible, after a short delay, in response to a mouse hover, or after the owning element receives keyboard focus.

This functional definition of tooltips includes keyboard accessibility, and that’s a significant improvement over mouse-only behavior. The specification also implies that the purpose of tooltips is to provide an accessible description:

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.

The ARIA Authoring Practices Guide (APG) has an article about providing accessible names and descriptions, which includes this definition:

An accessible description is also an author-provided string that is rendered by assistive technologies. Authors supply a description when there is a need to associate additional information with an element, such as instructions or format requirements for an input field.

Okay, so if the information in a tooltip serves a need to provide additional information, then it should be conveyed as an accessible description, otherwise assistive technology users won’t get that information. This makes sense of the recommendation to associate tooltips with aria-describedby.

But then, if the tooltip is associated with aria-describedby, what’s the meaning or function of the tooltip role itself?

As it turns out, the answer is — none at all. It doesn’t convey any meaning because it has no unique semantics, the spec definition is functional. Yet it doesn’t actually make any functional difference either.

Test results for role="tooltip"

To verify that, I created a simple test page for tooltip semantics.

This is not a usable script, it doesn’t conform with 1.4.13, and it doesn’t even have mouse events. It’s purely triggered by focus events, to test how aria-describedby and role="tooltip" affect the tooltip’s announcement. Here are the results:

I think those results are clear — the role does nothing.

What could it do, even in theory? There’s nothing there to implement — it doesn’t mean anything!

Are tooltips always accessible descriptions?

No, tooltips can also be used to show an element’s accessible name. But I would go further, and say that the only legitimate use-case for tooltips is to do precisely that.

Let me clarify that statement — I am absolutely not saying that tooltips should be used to provide an element’s accessible name. They should never be used for this. What I’m suggesting is that tooltips can be used (and should only be used) to provide a visual representation of an element’s accessible name, in cases where the name isn’t visible.

Application toolbars are a prime example, where the toolbar is comprised of graphical buttons. Ideally, each button should also have a visible text label, and the icon itself should be intuitively familiar. However that’s not always possible, given limited space or design constraints, or where an application’s unique functionality can’t be represented by already-familiar icons.

Providing a tooltip for each of the buttons is a useful aid for sighted users, who can then hover or focus the buttons to clarify what they do. Most desktop applications have tooltips on their toolbar buttons, and many users rely on them (myself included, although they’re rarely keyboard accessible).

But for non-sighted and screen reader users, every button still needs to have an accessible name, which is typically defined with aria-label, or using visually-hidden text. That text would need to describe the button’s function, such as “Save my settings” or “Fire phasers” or whatever the button does … which is precisely what the tooltip would also say!

So the tooltip only benefits sighted users. Not only is semantic declaration and association unnecessary, it’s actively pointless, or even counter-productive.

If the tooltip has the same text as the button’s accessible name, then associating it as the button’s accessible description (with aria-describedby) would cause the same text to be announced twice. Alternatively, if it’s associated as the button’s accessible name (with aria-labelledby), then the end result is same as if it wasn’t associated at all, since the button already has an accessible name.

Why is that the only legitimate use case?

If the tooltip provides additional description, and that information is needed, then it must be accessibly conveyed to all users. However this is impossible to achieve with tooltips, because tooltips are only viable if hover or focus is possible. (And if the information isn’t needed, then neither is the tooltip.)

Touch interfaces don’t have discrete hover or focus states, so there’s nothing to trigger the tooltip that wouldn’t also click the control. Even in mobile screen readers, navigating links doesn’t focus them unless an external keyboard is used (although aria-describedby and aria-labelledby associations are announced, they don’t require the tooltip to be rendered). The same is true for most virtual pointer interactions, such as voice control, eye-tracking, or grid-based switch navigation. These interactions can’t usually generate hover states, and can’t necessarily generate discrete focus states either (for the same reason as touch interfaces).

If the information is essential for all users, then it must be defined in regular static text. If it’s only defined in a tooltip, then some users will always be excluded, and there’s no way around that — the whole idea of accessible tooltips is a contradiction in terms.

But still, there are cases where sighted users may benefit from a visual representation of information that’s already available to screen reader users, like the toolbar buttons example I mentioned earlier. This is not required for conformance, and it still doesn’t benefit touch-only users, but it can be particularly helpful for desktop users with cognitive issues relating to memory or symbol recognition.

Tooltips aren’t useless, they’re niche

Tooltips can help sighted users to comprehend visual interfaces, and that’s all they can do. They don’t provide any benefit to assistive technology users, and only appear to in cases where they’re being misused.

In other words — tooltips are presentational.

(mic drop)

Resources

• Tooltips in the time of WCAG 2.1 (Sarah Higley)
• tooltip role (ARIA)
• Providing Accessible Names and Descriptions (APG)

Image credit: Ahmet Kurt.