Use Carbon tooltip instead of browser generated `title` tooltip for all components

griffindvs commented 3 years ago

Environment

Operating system: MacOS Big Sur (11.4)

Browser: Chrome 91

Testing Tool: Manual

Detailed description

What version of the Carbon Design System are you using?

carbon-components: 10.38.0 carbon-components-react: 7.38.0

What did you expect to happen?

The MultiSelect.Filterable, ToastNotification, InlineNotification, and NumberInput Carbon React components each take prop inputs for text to be displayed in the default browser tooltip (internally using the title attribute). Some components just take a string while others take a function that returns a string (to allow for translation messages for singular/plural). These tooltips contain information that is not displayed elsewhere, so they should be resized when the browser is zoomed-in to allow those with varying levels of vision to read the text.

What happened instead?

The default browser tooltips do not resize as the browser is zoomed-in. This means that when you go from 100% to 200% zoom on a webpage, the browser tooltip remains the same size. Because these tooltips are generated by the browser and merely generated from a title attribute, there is no workaround to force these tooltips to resize. This problem is noted in the MDN Web Docs for the title attribute which notes that "if a tooltip effect is desired, it is better to use a more accessible technique" instead of this built-in tooltip. For Carbon, a more accessible technique could come in the form of integrating the custom Carbon tooltip into these components.

What WCAG 2.1 checkpoint does the issue violate?

Success Criterion 1.4.4 Resize Text

Steps to reproduce the issue

Use the InlineNotification component as an example (though there are others).
Input a string for the iconDescription prop.
Build and view the webpage.
Zoom the browser to 200%.
The tooltip on the InlineNotification close button does not resize.

CodeSandbox: https://codesandbox.io/s/carbon-tooltip-issue-n91ng?file=/src/index.js

Additional information

Screenshot at 100% Zoom:

Screenshot at 200% Zoom:

tay1orjones commented 3 years ago

Thanks for the suggestion here @griffindvs! I marked this as a proposal for the team to discuss and consider moving forward because as you note, there's not really a way for us to impact the browser generated elements like title hover/tooltips.

abbeyhrt commented 2 years ago

related: #10173

tay1orjones commented 2 years ago

sstrubberg commented 2 years ago

Notes from backlog cleaning today:

Many reports of "how do we get rid of that tooltip that pops up" from our users. (referring to the native browser one)
We need to be consistent throughout our components when using the native browser tooltip vs. using Carbon's tooltip.
The challenge pointed out in this particular issue appears to be more of a chromium bug, not us (Carbon) (this doesn't necessarily change how we respond.
Possible Carbon/Accessibility Guild (CAG) conversation to determine the need a the violation.
MultiSelect.Filterable, ToastNotification, InlineNotification, and NumberInput were all listed in this issue as being inconsistent and could use Carbon's tooltip. Are there more?

mbgower commented 2 years ago

@sstrubberg asked me to have a look at this.

I would not disagree that improvements on the user agent default "title" tooltip behaviour are worth pursuing. Many of us have been waiting for user agent 'fixes' for decades. Desired changes include:

ability to increase text with browser zoom (Resize text)
ability to appear on keyboard focus (Keyboard)
ability to dismiss with Esc (Content on Hover or Focus)
persistence until dismissed (Content on Hover or Focus)

Those are all things that meet various WCAC requirements (as noted in parentheses).

Carbon piggybacking on the title functionality doesn't create a new problem. One can argue that it is a browser bug -- not something Carbon needs to solve. But like a lot of really annoying 'established' user agent behaviour there is no sign of browsers chomping at the bit to alter the status quo.

So if Carbon has an established way of achieving improved, consistent tooltip behaviour on its components, I think it is definitely something to pursue.

PS In an ideal world, Carbon would have a way of letting users set preferences and let them decide on how they want tooltips to behave. If Carbon ever pursues personalization, this would definitely be a feature to consider.

tay1orjones commented 1 year ago

Something else to consider - if we update all components to use Popover instead of title, what happens to existing usages of title?

Seems like there are two options:

No impact - title behaves as it does already and the user would potentially see both a Popover and and title overlay if the consumer has configured it that way.
Use title for the Popover content (if provided), and do not set title attributes within components.

For #2, title would almost always need to be plucked out of ...rest (or removed from proptypes), and as a coverage for legacy usage, use the value within popover content and generally do not ever set title within the components.

I'm not sure if there are any accessibility implications with #2 but it feels like the better choice from both an end-user perspective and also wrt developer experience.

Related slack thread where this idea came up.

carbon-design-system / carbon