Add a mechanism for accessible tooltips in core

[joedolson]

While we've worked hard to eliminate usage of the title attribute across most of WordPress core, there is still an occasional need for that type of contextual information, and the lack of it is a barrier to resolving some issues (e.g. #50921) and removing some of the last instances of the title attribute.

An accessible tooltip will need to meet these criteria:

1) Be available either via the mouse, via the keyboard, or via touch.
2) Be persistent until dismissed
3) Support primary & auxiliary usage, dependent on whether the tooltip is the sole name of the control or an elaboration of existing text.

Useful reference on accessible tooltips: ​https://inclusive-components.design/tooltips-toggletips/

[oglekler]

Proposal for tooltips in settings

[oglekler]

There are different possibilities for tooltips usage:

• alternative to title attribute
• standalone helper

We need them to:

• Creating clean, more modern design in the admin and reduce visual complexity and clatter.
• Providing unified tool to plugins and themes developers for tooltips in the admin (right now some of them have their own implementations)
• Standardizing tooltips usage in WordPress to make sure that they are aria friendly and provide expected behavior in core, themes and plugins

References:
​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tooltip_role
​https://m2.material.io/components/tooltips#theming

[oglekler]

Here is a need for more advanced Tooltip implementation
https://core.trac.wordpress.org/ticket/21583#comment:55
and it looks like it can depend on this one's functionality.

I wonder if Tooltip in jQuery UI is good enough to cover our needs and meet all accessibility requirements, or we need to look for another solution.

[davidbaumwald]

I apologize if this was discussed elsewhere, but I don't see anything here. Has any consideration been given to using the ​Tooltip component from the block editor?

If not, I feel like this might be something that should be considered, and might be improved if there are a11y issues.

[joedolson]

The block editor tooltip doesn't seem very suitable, based on how I see it used - it's hidden from screen readers, it's not dismissable, and depends on aria-label for accessible naming.

We could work on improving that - I think it would require a pretty much total refactor. The way its used in the block editor, the only change that would be needed within that context is making it dismissable; but for broader usage, it would also need to be communicated to screen readers and not be dependent on aria-label for naming.

[joedolson]

See: ​https://github.com/WordPress/gutenberg/issues/48222

[oglekler]

I believe one of the requirements is an ability to use this tooltip for plugin and theme developers by adding its data in $args parameter of add_settings_field() function and possibly calling it by itself.

@davidbaumwald can we use the Tooltip component this way?

[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.

[oglekler]

This could also be a tooltip: #58312