Demonstration mostly follows ARIA Authoring Practices guidance for tooltip widget and mirrors Example 4 from ARIA1 in WCAG 2 Sufficient Techniques.
role="tooltip".aria-describedby.aria-hidden so that they are discoverable only via the describedby reference.The ARIA Authoring Practices say a “tooltip is a popup that displays information related to an element.” It also indicates that the Tooltip Widget is “a work in progress.”
The Tooltip design pattern has significant problems: Screen readers tend not to report aria-describedby associated element values unless two things are true: the trigger element is an interactive element and the trigger element gets keyboard focus. Because of this, the only practical use for the ARIA Authoring Practices recommended implementation of Tooltip is on an interactive element.
In the case of an ARIA Tooltip Widget on an input, link, or button, the tooltip can be used to provide some extra descriptive context (see the examples under “Valid Demonstrations,” below). However, using a link or a button solely as a trigger for a tooltip — where the link or button is not used for interaction but as something to attached a tooltip to — potentially fails conformance to WCAG 4.1.2 Name, Role, Value. Minimally, it creates a situation in which the native semantics of the element do not align with the purpose of the element — the tooltip would report as a link or a button, while its purpose would be only to display a tooltip. This problem might be addressed by overriding the reporting of the button or link role via aria-roledescription, but that technique is limited, since aria-roledescription does not have robust support yet.
The “Experimental Demonstrations” below are all problematic in one way or another. The dfn element example does not work with some screen readers. Even though accessibility properties inspection tools demonstrate that the element's description is exposed, some screen readers do not read the value of the referenced element, regardless that the ARIA specification indicates that any element in the base markup can have aria-describedby.
Similarly, we try to get around the reporting of the role of link, since the an element with a tooltip should not really be a link (unless of course its actual function is to link to something). We try role=application and variously turning off the role with role=presentation and role=text (no longer, in ARIA 1.1, a valid role attribute value). We also try reassigning the ARIA role by using the ARIA 1.1 new attribute aria-roledescription.
And finally there is an experiment using role="term" and its related role="description". The term-definition pairing is supposed to emulate the dt / dd pairing of a definition list, and the spec says use an aria-labelledby association to achieve the relation. The problem here is that, were the technique to work, the spec says to override the name calculation of text with the value of the associated element pointed to by the IDREF. The pattern does not seem very well thought through, since the term in a description list is not overridden by the description.
As a final concern, we ought to consider the utility of a tooltip. Is it a pattern we should be using? Adam Silver writes in “The problem with tooltips and what to do instead” that the tooltip pattern has inherent issues, which disproportionately affect users with disabilities:
role=text was removed from ARIA 1.1 and is no longer considered valid.)