Heading level dropdown: remove obtrusive tooltips in favor of visible text #56035
Conversation
afercia
added
[Type] Bug
afercia
requested review from
kevin940726,
Mamaduka and
ellatrix
as code owners
|
Size Change: -1.58 kB (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Quick screenshot to visually compare other dropdown menus in the block toolbar that use both icons and visible text:
|
There was a problem hiding this comment.
Thanks for the PR, @afercia!
This PR also adds a stylesheet to the component, which is only used to increase a little the horizontal gap between the heading icons and the visible text.
Personally, I think it would be better to update the style of the dropdown menu itself in a separate PR. For example, even with the align control, the space between the icon and the text looks a little cramped for me.
The gap between the icon and text is 4px, which was changed from 8px by #50277. 8px feels more natural to me in a UI where icons may be pressed, like this dropdown menu.
@jasmussen @jameskoster Please let me know if you have any opinions on this point 🙏
|
@t-hamano thanks. Yes that could be an option. |
Serendipitiously I think @jameskoster has been working on dropdown menus lately, and had thoughts on this exact thing. |
I'd agree #50277 didn't take into consideration buttons with a pressed state. The pressed state just makes more visible what the actual SVG The editor SVG icons have varying glyphs: some glyphs take only a part of the actual SVG While #50277 improved the look of icon + label for some use cases, I think it actually made it worse for other use cases and that change should probably be reconsidered. To illustrate, here's some examples with icons glyphs that have different widths, thus producing a visual uneven spacing:
That said, this PR is not about the padding. It's about the functionality. I adjusted the padding only because, for this menu, 4px looked ugly.
I will remove the CSS change, but the padding issue should be addressed in a separate PR taking into consideration all the use cases. |
There was a problem hiding this comment.
LGTM! Since this PR is about improving functionality, I think we can merge this PR and address the issue of the gap between icon and text in another PR.
Desktop
Mobile
One thing I came up with is that if we make the entire icon and text "pressed" style as shown below, it might be okay to have a gap of 4px between the icon and the text.
@jameskoster If there is an issue number for improving the design of the dropdown, please let us know.
|
The spec for the new flyout menu component(s) can be found in #55933. One thing to note relating to this PR; that spec does not include a configuration where MenuItems are selectable and have a decorative icon. So at some point we'll need to make a decision about how to proceed here, either no icons, or icons only (with tooltips): 
|
Personally, I like the idea.
@jameskoster I'll comment on #55933 and ping you there
I'm not sure I understand why it should be either one or the other. Icon + visible text is fine to me, when the visual hint provided by the icon adds clarity. Also, I would like to point out that the button component, which is at the base od the dropdown implementation, does have props to show both the icon and text and it does have a pressed state style that includes the text, see the storybook: https://wordpress.github.io/gutenberg/?path=/story/components-button--icon&args=isPressed:!true;text:Some+text;aria-pressed:true
|
|
Turns out the reason why the dark background doesn't apply to the text is that these menu items use a |
|
Noting that the gap issue is no different from what already happens with other dropdown menus, fgr example the Align dropdown:
As such, I will leave it as is for now. This should be addressed holistically, |
@jameskoster Why are these the only two options? I think that valid arguments for having visible text has been brought up over and over. That icons are "globally recognised" may be an overstatement, but they can enhance and make it easier to select the correct options even when there is text. |
|
Does "Heading 2" convey more information than the "H2" icon? Seems duplicative; so I can see how an icon-only instance of this particular case would be fine. Anyhow, I'd like to further explore how level switching and transforms are connected in #55520. |
I kindly disagree. As mentioned several times, text is always preferable, Icon-only needs to be avoided. |
The nuance with this particular control is that the icon is representative of text. H1 is graphically depicted exactly as "H1". In this case, we may not even need icons, but just text. Also, I'd say that's your preference. There are many instances throughout all sorts of experiences where universally accepted iconography promotes a much more understandable UI. For example, the bold, italic, and link controls in the block toolbar (and just about every other text editing UI). |
Regarding this specific case: But still it is not text. SInce it's not text, we need to give the button an accessible name via
Is not accessible because, visually, it shows Regarding the general icon-only issue:
There's tons of research and data about icons not being universally understandable. To mention just one of them: Nielsen Norman Group Also, we need to expand a little from our Western-centric cultural background and include other cultural backgrounds where symbols may have completely different meanings. The checkmark symbol is probably the case (not the only one) that better illustrates these cultural differences. In Swedish schools, in Finland and in Japan, the checkmark means 'wrong'. So no, I wouldn't say this is 'my preference'. |
If "H1" is an icon, how is this a violation? Is a trash can icon for "Delete" also a violation?
A icons-less experience will certainly be a less usable experience for everyone. There is a balance; repetitiveness and increased cognitive load is not it. I'd argue a "H1" icon on a heading block is clearly the Heading Level 1. There is no room for misinterpretation and unexpected results by selecting it.
That is your perspective; and totally fine, though I don't particularly share the need to change this case. Perhaps you'd like to explore alternatives to see how to best expose selections, though I'm thinking the checkmark is overwhelmingly the supported icon for such use cases. |
I'm not sure i know how to explain it more clearly. Also, the H1 icon and a 'Delete' icon are very different cases. The first one visually looks like text. The second one is graphics. DId you take the time to read the WCAG criteria? There is an Understanding Label in Name link there.
I woudn't say it's my perspective. The checkmark is just an example. I thought it was clear it was an example. The general principle applies to all icon. I pointed to an authoritative resource, the Nielsen Norman Group, which clearly explains why icon-nly is a problem, That is based on actual research, user testing, and data. There's plenty of research around icon-only and they all coem to rhe same conclusion. I'm not sure our time is best spent on cycling back over and over on the same points. From my side, I already provided my feedback and recommendations. |
I am of course quite familiar, yes.
I concur. 👍 |
Fixes #50402
See #55927
See #46003
What?
Removes the dropdown menu heading level tooltips in favor of visible text.
Why?
Since the dropdown menu has now a vertical orientation, the tooltips of the menu buttons hide the other buttons on hover and focus. This is a functional and usability / accessibility problem that needs to be fixed.
I'd also like to remind that icon-only buttons have inherent usability and accessibility problems. Their usage should be limited to only the cases where there isn't enough space to use visible text. This is not the case, as there's a lot of space to show visible text.
How?
Makes the dropdown option buttons use both an icon and visible text.
Having both the icon and visible text seems to be the most appropriate solution here. The icon represents a visual hint that may help some users, while the visible text is universally accessible to everyone.
Other examples of dropdown menus that use both an icon and visible text are already present in the block toolbar, for example the block switcher menu and the More options menu.
This PR also adds a stylesheet to the component, which is only used to increase a little the horizontal gap between the heading icons and the visible text. This is not uncommon, as there are already components that override the button component default gap value, for example the Link control and the block switcher.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Before:
After: