Missing accessibility best practices information for Tooltip on non-focusable UI

[BrendanMcK]

Environment Information

• Package version(s): 7.146
• Browser and OS versions: any

Describe the issue:

The documentation for Tooltip should be updated for how to handle cases where a tooltip is desired around some UI that is not itself focusable.

(Edit - re-worded this as 'not itself focusable' vs interactive, since it's specifically the lack of keyboard focus that's the issue here.)

A good example of this is Tooltip only on overflow example on that page. When the text is made to truncate, mouse users can access the full text via the tooltip, but keyboard users cannot, as there is no element to tab to. (Screenreader users may or may not be able to access the content, depending on whether the content in the DOM is merely truncated via CSS for display, but this may not work with other types of truncation or if the tooltip is conveying information that's not in the DOM.)

Adding tabindex=0 might help somewhat; but this now results in an element that is interactive, but without a clearly defined ARIA role. Adding role=button would be inappropriate here, as the UI element is not actually executing a command or acting like a button; it is merely focusable in order that focus has somewhere to dwell to cause the tooltip to appear.

While it may tempting to discourage the use of Tooltip around non-interactive items outright, it does appear that in reality there are occasionally cases where this is needed, so some robust best practice should be investigated and presented, and supported by the control itself if appropriate.

This issue likely also occurs where tooltips are placed around disabled buttons to explain why the button is disabled; disabled controls are generally not focusable, so again keyboard users have no way to activate the tooltip.

[gouttierre]

@BrendanMcK - thank for reaching out and highlighting this item.

@tomi-msft - Could you review the suggestions for improving the ToolTip on non-focusable UI?

[smhigley]

@BrendanMcK thanks for logging the issue! It highlights a problem with tooltip use that is pretty systematic within Fluent. We really really should not be using tooltips for overflow text -- aside from keyboard accessibility, it's also inaccessible with touch, voice control, switch, eye gaze, and essentially anything that isn't a conventional mouse or trackpad. It also perversely shows up the most for those who can't use it, or have trouble using it, since truncation is more likely on smaller screens (which are more likely to be phones and tablets), and at high zoom, where tooltips are known to be difficult to navigate with a magnifier.

They're also a pretty bad user experience overall, even when keyboard accessible -- imagine needing to hover over every grid cell or menu link just to read it 😱. And even then, they won't be accessible through touch, switch, voice, etc. My goal is to push for removing overflow tooltips from all base Fluent controls in vNext.

The main alternative for tooltips on truncated text is to wrap the text instead of truncating it. I've added an example of wrapping text and a guidance section on our Nav example, but it's definitely needed in more places. For longer truncation examples, another option could be to include a button that expands the full text. Other non-truncation-related tooltips on static content could also be converted to a (?)-style button that toggles display of the tip, so that it's no longer triggered by hover.

Disabled buttons are another excellent example of where people currently use tooltips, but where we should have better guidance why to not use them, and what alternatives exist. In addition to the same access issues that apply to other tooltips, disabled buttons do not have contrast minimums, and are often difficult to perceive. Generally, if a button or other form field has any interaction whatsoever (tooltip included), it should not be disabled b/c there's a good chance it won't be visually perceivable enough to interact with. If explanation is required for why a form field is disabled, that explanation could be statically available on the page or through a "help"-style toggle button. Another option would be to revisit the design as a whole -- I forget who said it, but the maxim "design is like comedy -- if you need to explain it, it's not good" seems appropriate.

I hope that helps! It's a great question, and I really hope to get this information into Fluent's documentation. We get a lot of bugs that boil down to poor use of tooltips (often encouraged by our own bad internal use of tooltips in components and examples), so it's definitely a widespread problem.

[msft-fluent-ui-bot]

Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.