[wp-trac] [WordPress Trac] #51006: Add a mechanism for accessible tooltips in core

[WordPress Trac]

#51006: Add a mechanism for accessible tooltips in core
-------------------------+--------------------------------
 Reporter:  joedolson    |       Owner:  joedolson
     Type:  enhancement  |      Status:  accepted
 Priority:  normal       |   Milestone:  6.3
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  tooltips     |     Focuses:  ui, accessibility
-------------------------+--------------------------------

Comment (by joedolson):

 Specifications for an accessible tooltip for WordPress:

 Definitions: 'source' refers to the object a tooltip is related to.
 'content' refers to the visible text content of the tooltip. 'name' refers
 to the accessible name of the control itself.

 1) Tooltips are primarily supplemental information, and should not
 override the name of the source. This means they should not depend on
 something like `aria-label` on the source.

 2) Tooltip content should not require a move of focus.

     a) When the tooltip is also the name of the control, rather than
 supplemental information, it should be associated as a label field, either
 sourced from `aria-label` or using `aria-labelledby`.

     b) For supplemental tooltips, the content should be associated with
 the source using `aria-describedby`. E.g. `<input type="name" aria-
 describedby="tooltip-1"><div id="tooltip-1">Your full first and last
 name</div>`.

 3) If there is interactive content in a tooltip, it must be next in tab
 sequence after the source and be accessible to a screen reader or keyboard
 without dismissing the tooltip.

 4) All tooltips must be dismissable without removing focus a source. When
 a tooltip appears on focus, it should be dismissable using `esc`. This
 will mean ensuring that the keyboard `esc` event doesn't trigger
 unexpected closures when used inside modals or other `esc`-closable
 contexts. It will also require a visible close button that can be used by
 pointer devices to close the tooltip and move focus to the source
 *without* re-triggering the tooltip.
     a) Note: the close button will also need to meet WCAG's requirements
 for control size.

 5) The tooltip should not use `role="tooltip"`, `aria-haspopup`, or `aria-
 live`. The role has no significant support, and as written does not allow
 interactive content. Tooltips are not popups, and aria-live should not be
 used for naming and descriptions of static content.

 6) Tooltips should be available for touch interactions. This ensures that
 a) non-hovering pointer AT will be able to get the tooltip information and
 b) the friction of using controls on mobile will help reduce excessive use
 of tooltips, since while they should be possible, they should *not* be
 overused.

 7) Tooltips should *not* support formatting such as heading, bold text,
 italics, etc. These will not be conveyed to screen readers.

 8) Interactive content should be strongly discouraged and avoided if at
 all possible. If the tooltips simply do not support it, that would be
 entirely adequate.

 9) Tooltips should only be supported on interactive sources - buttons,
 links, inputs, etc.

 10) The `title` attribute should not be used on the source.

 11) There should not be a timeout on the tooltip.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51006#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform