Icon tooltip uses a button element, JAWS users are lead to believe there's an action associated to the Icon

[MarcelPoirier]

Environment

Operating system
Windows 10 running

Browser
Firefox 79.0

Assistive technology used to verify
JAWS 2020

Detailed description

The Icon tooltip is rendered using a button element. When a JAWS user tabs to the icon, JAWS will announce the tooltip text (correct) but then go on to say " button. To activate press Enter". This is misleading since pressing enter does nothing - there's no action associated to the icon.

What version of the Carbon Design System are you using?
10.16.0

What did you expect to happen?
Tooltip text should be read out without telling the user to press Enter

What happened instead?
Jaws tells the user to press Enter

Steps to reproduce the issue

1. Step one
   Running JAWS, tab to any Icon tooltip

Additional information

Can be reproduced https://react.carbondesignsystem.com/?path=/story/tooltipicon--default

[joshblack]

Most likely we should update this to be a toggletip as defined: https://inclusive-components.design/tooltips-toggletips/ 👀

[emyarod]

the toggletip still makes use of button elements right>? so is the problem with our components that we open the tooltip on focus? that seems to be where we differ from the toggletip pattern

[joshblack]

@emyarod yeah, I think that's the only difference 👀

[joshblack]

@dakahn looking at some of the implementations out there it seems like tooltips are effectively a visual language and they can be implemented either with aria-describedby or aria-labelledby and are then styled to look like a tooltip?

For usage with <button>, it seems like it should specifically be a toggletip that will control the expansion using the disclosure pattern.

Reference:

• https://sarahmhigley.com/writing/tooltips-in-wcag-21/
• Example with icon button tooltip: https://codepen.io/smhigley/pen/KjoerX

[dakahn]

It's hard to code around this JAWS peculiarity. A button triggering a tooltip is the expected interaction and I'd naively assume a JAWS user could properly infer what's going on in the given context. It seems like the button isn't the bug to me, but there's potentially improvements we could make around announcing the show/hide state of the dialog the button triggers perhaps?

[carmacleod]

A button triggering a tooltip is the expected interaction

It Depends... ;)
(this is the standard accessibility answer for just about anything...)

If the button's purpose is to invoke an action (i.e. the usual purpose for a button), and the tooltip shows the button's name or description, then the usual interaction is to trigger the tooltip on focus or hover and read out the button's name (and description, if any). Activating the button (space/enter or mouse click) will invoke the action. In the Carbon TooltipIcon example, which is linked in this issue, nothing happens when the "Filter" button is activated because it's just an example, and the application logic hasn't been added. (i.e. in a real app, something would get filtered).

However, if the button's sole purpose in life is to show a "tooltip" (e.g. ℹ️), then as @joshblack pointed out, it's actually called a "toggletip", and the usual interaction is to only show the tip on demand, i.e. when the user clicks the button (on mouse click or space or enter). Hide it when the user either clicks the button again, or types escape, or the button loses focus. In other words, don't show the tip on focus or hover. The Carbon Tooltip is an example of one of these ℹ️ buttons. In this case, you don't want the screen reader to read the tip before the button is clicked, so you don't want to point to the tip content with aria-describedby. You should, however, give the button a name (using either aria-label or aria-labelledby or assistive-text hidden text content, or even visible text content). For example, the button's name could be "info" or "help" or something like that.

[dakahn]

Thanks for the guidance @carmacleod! If it's okay with you I think we could improve our design guidance around these components using some of the points you raised about tool/vs toggle tip. And we're definitely building/designing around this problem in v11 👍🏽

That said, the current implementation is intended behavior (though admittedly awkward. Closing this as wont-fix