-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve : showTooltip documentation #66673
base: trunk
Are you sure you want to change the base?
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Thanks for your PR!
Actually, that's not the recommended usage for tooltips.
|
Hi @afercia 👋 I have updated the docs as per your recommendation. Thanks |
Thanks @Vrishabhsk it looks good to me. I'd appreciate a review from @WordPress/gutenberg-components |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afercia I have some questions about this.
Tooltips must be used only to visually expose the label of controls that don't show visible text.
This kind of makes to me, but then there are cases like this With Tooltip example for ToggleGroupControl. Is this acceptable or not? Does it matter whether something like "A→Z" (or "AB"/"Ab" for capitalization) is rendered as a string or an icon? Maybe there is a way to rephrase this guidance because currently the "why" is unclear.
Tooltips usage must take into account the showIconLabels preference
As discussed in #61763, we have the conundrum where showIconLabels
is not a wp-components feature. This guidance can't really belong here, and to be honest I think it is unrealistic to expect all devs (first and third-party) to know about and test for the showIconLabels
feature. I thought the showIconLabels
feature was intended to be something that "just works". If it's not, then we need to bake that feature in at the component level. Have we considered ways to automate this consideration about the redundant tooltips in showIconLabels
mode?
No, that is not acceptable because it introduces a mismatch between the visible text and the accessible name. As explained several times, that is a barrier for sighted screen reader users, voice control / speech recognition users etc. Also, it's a violation of WCAG Label in Name. That kind of usege of tooltip is closer to the old, deprecated, usage of the title attribute to 'expand' soem information or add descriptions.
That's the reason why I opened #61763 6 months ago, still no great progress though. I understand the approach I proposed in #61824 may be not ideal and I'm totally open to better options. I'd like to remind again that buttons that only show an icon are a problem for accessibility. We need to provide consnistent ways to make them accessible. Also, it's pretty common on operating systems and apps to have option to display:
All the 3 options have advantages for specific users needs. For example, only icon may help users with dyslexia but they are not accessible for other users. The only way to solve this long standing issue is to make sure any design provides a design for this preference as well and clearly document why. |
On the contrary, wouldn't something like "A→Z" be what the WCAG clarifies as being "symbolic text characters", rather than "expressing something in human language"? It would be the same as if "A→Z" were an icon image. These are not considered "visible labels", so the tooltip is only exposing the accessible name of the button, just as it would for an icon button. For example, would a rephrasing like the following work? Does it capture the intent of why this guideline is in place? "Tooltips must be used only for visually exposing the accessible name of controls where the accessible name is not clear in the default visual state. The tooltip must not be used to convey additional information (such as usage hints) about the control." And then we could accompany that with a pair of Do and Don't examples (cc @auareyou @juanbuis who are working on improving docs). It may also be useful add a recommended pattern for conveying additional information about the control, instead of using a tooltip. |
How about we discuss the |
Well, as the WRC explain that may be considered 'Images of Text'. When images contain text, their alt attribute must be the represented text. Similarly, if we consider this case as equivalent to an image, then the accessible name should be Anyways, I see many don't understand well the consequences of a mismatch between the visible label and the actual accessible name. I would encourage anyone to use Voice Control (on macOS) or other speech recognition software and try to activate any control where the visible label mismatches the accessible name. |
This isn't consistent with the fact that we use "images of text with symbolic text characters" such as "B" or "H2", which have an accessible name of "Bold" (for text style) or "Change level" (for headings). And to be clear I'm not arguing about specific cases, but rather that we should figure out the appropriate verbiage to issue this accessibility guidance in our documentation. The original verbiage "Tooltips must be used only to visually expose the label of controls that don't show visible text" does not cover the symbolic text characters case. My suggested tweak "Tooltips must be used only for visually exposing the accessible name of controls where the accessible name is not clear in the default visual state" aims to be generic enough to cover those cases. |
I would argue that the "Change level" example isn't the best example as 1. the symolic text is dynamic 2. it is used to communicat ethe selected vallue and not the function. Regardless: the proposed text: "Tooltips must be used only for visually exposing the accessible name of controls where the accessible name is not clear in the default visual state" isn't ideal because it doesn't make clear that when a control already has visible text that matches the accessible name, tooltips must not be used. I wouldn't be opposed to expand the documentation with a few examples in the 'usage' or 'best practices' sections. |
What?
README.md
for components that haveshowTooltip
prop.Why?
showTooltip
prop in various components #66523