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.
Environment Information
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=0might help somewhat; but this now results in an element that is interactive, but without a clearly defined ARIArole. Addingrole=buttonwould 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.