Tooltip accessibility

[jgiardino]

UPDATE on this issue

After reviewing details documented below with others on the team, the decision is to recommend that tooltips not be used on static elements. More information is noted in the design repo: patternfly/patternfly-org#1108 (comment)

Ability to support either aria-labelled or aria-describedby for interactive elements is expected.

/END UPDATE

This issue is to capture the accessibility requirements related to tooltips. As part of this issue:

• screen reader tests should happen to confirm that support is provided as expected. Testing can be completed in the latest versions of JAWS using Chrome, NVDA using FF, and VO on mac.

Resources related to creating accessible tooltips:

• https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip
• https://inclusive-components.design/tooltips-toggletips/
• Also note that tooltips are expected to be dismissible via Esc key per a new WCAG item related to hover/focus

[rachael-phillips]

Hi, I'd like to follow up on this issue because I haven't seen a lot of activity here in a while. How is this issue going?

[jgiardino]

I created the following issues to capture updates we know are needed:

• Tooltip - support aria-label #1458
• Tooltip - persistent on hover #1457

Remaining tasks for this are:

• Understand what examples we're providing in design documentation for this, and make sure all use cases are supported (e.g. some use cases are currently supported, some use cases might not be supported).
• Use cases that currently are not supported (at least in JAWS) are ability to provide a description for something that is outside the context of a form.
  • This might be addressable with additional screen-reader-only that duplicates the information that displays in the tooltip. But we would want to not use aria-describedby in this case to avoid duplication in screen readers that do support this case.

[jgiardino]

I captured different use cases where we would possibly want to include a tooltip, and noted what cases don't work for specific screen readers.

Something I tested was including tooltip text in a data attribute, and this works reliably well, and compared to aria-describedby, isn't much different (e.g. I included ". " to create the pause that happens between the element label and description).

@mcarrano @mcoker @jschuler I'm interested in your thoughts on this. Some possible options are:

1. Note what use cases work reliably well, and advise consumers to do one of the following in cases where tooltips do not work:
   • For non-interactive elements, use a popover instead
   • For non-interactive elements: make the tooltip toggle inaccessible to screen readers, and immediately follow it with a <span class="pf-u-screen-reader"> that includes the tooltip contents.
2. Modify our implementation to provide the tooltip text in an alternate way that all screen readers can perceive (e.g. put text inside a data attribute and render it on screen with css), and do not use aria attributes to use text defined in the tooltip element.
3. A mix of the first two bullets. For non-interactive elements, use .pf-u-screen-reader text. For interactive elements, in cases where the screen reader nav method triggers focus, then aria-describedby also works as expected. Since this attribute isn't present until focus is triggered, then we can have css that makes contents of the data-tooltip attribute accessible to screen readers. And if focus triggers the addition of the aria-describedby attribute, then we can have css that makes the data-tooltip text inaccessible to screen readers.

Use case / SR	JAWS	VO	NVDA
Form element with aria-describedby	works	works	works
Button with aria-labelledby	works	works	works
Button with aria-describedby	Tab - works; Arrow - does not announce aria-describedby	works	works (in the react example, arrow key works, but not in my static example)
Non-interactive element (e.g. a static icon) with aria-labelledby	Tab - works; Arrow - element is ignored (e.g. if aria-hidden is applied to the visible element)	works (testing static examples)	works
Non-interactive element with aria-describedby	Tab - works; Arrow - does not announce aria-describedby	In the react example, does not announce aria-describedby. In my static example, Tab will announce aria-describedby	works (in the react example, arrow key works, but not in my static example)
tooltip text is in data attribute	works	works	works

[mcoker]

Is there any downside to using data-tooltip? That looks like the simplest solution. The . at the beginning is a little odd but otherwise it looks like that works the most reliably with the least amount of effort on the consumer to choose the right approach.

[jgiardino]

Using data-tooltip might require that we submit an issue to tippy.js (?) to provide the ability to not have aria-describedby used on the toggle, so that we can use this method instead. Although that might not be a blocker, since it would just result in redundancy in the cases where aria-describedby is supported.

I agree the . is weird. I wanted to recreate a similar experience that you get with aria-describedby where you hear a pause between the label and description, but maybe that isn't critical given how odd this seems.