Demonstration mostly follows ARIA Authoring Practices guidance for tooltip widget and mirrors Example 4 from ARIA1 in WCAG 2 Sufficient Techniques.
aria-hiddenso 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
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=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
And finally there is an experiment using
role="term" and its related
role="description". The term-definition pairing is supposed to emulate the
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=textwas removed from ARIA 1.1 and is no longer considered valid.)