Optional Inline Labels in Toolbar

[tomjn]

Is your feature request related to a problem? Please describe.
Icon only toolbars are fine for some people, and some have a preference for it ( e.g. myself ).

However, some people are unable to effectively use icon only toolbars, perhaps it's their preference, but for some people it has an a11y aspect. This could be similar to face blindness or forms of dyslexia.

For those people tooltips are not enough, and the friction of hovering over each button and waiting for the tooltip to display is immense.

Research indicates that a combination of icons and texts yields the widest and greatest recognition speed possible, at the cost of space

Describe the solution you'd like

MacOS solves this problem by providing options when customising toolbars, e.g.:

Icons only:

Icons and text:

Text only:

I've mocked up what an icons and text mode may look like in Gutenberg:

To me this looks like a clear improvement for some, and makes for much larger target areas on larger devices. I believe the icons only should remain as the default option however

I'm unsure how it would look placed underneath as MacOS does. I'm also unsure how well a text only option would fair, but it would look a lot prettier than MacOS given the current Gutenberg UI styling.

[Luciaisacomputer]

This makes sense to me. I'd even prefer to have it as the default with a "minimal UI" as the second option to remove the labels.

[afercia]

Some background: "icon-only" controls (buttons with no visible text label) are problematic for many reasons. They're an accessibility anti-pattern as pointed out in the first Gutenberg accessibility report from the accessibility team.

They're also a big problem for speech input users, as well explained in #470 (comment)

A few previous related comments:

• "Responsive buttons" should have tooltips and use consistent CSS techniques #5358 (comment)
• Should we show an "Add" label next to the Block Library button on desktops? #7221 (comment)

[mapk]

Maybe we can add a checkbox in the Options modal which, when selected, turns on those icon labels? Something like this?

[afercia]

I'd love to see this explored. There are a few challenges, for example we can't predict the length of the labels when translated. Also, I'm not sure how to address other icon-only controls, for example in the block toolbar.

I wouldn't group the option under an "Accessibility" section: this would be a feature that can benefit everyone.

I'd consider to explore how the text label would look when placed below the icons. The text doesn't necessarily needs to be "big". It can be a bit smaller, as long as it's readable. For inspiration (Android):

This would save some horizontal space, even though there needs to be some spacing between the icons.

[mikelittle]

I have some kind of 'icon blindness' and struggle to distinguish one icon from another. So having a text option would be a really big help. In most apps, I turn it on whenever I can, though at least on the desktop, many already have them turned on.
I also agree it should not be an 'accessibility' option it should be a standard configurable option like 'top toolbar'.

[mapk]

I wouldn't group the option under an "Accessibility" section: this would be a feature that can benefit everyone.

That makes sense. Thanks for sharing!

[mapk]

Here are some mockups regarding this discussion.

Top: The icon only state.
Middle: Icons + text (side by side)
Bottom: Icons + text (underneath)

[mapk]

@enriquesanchez I heard you might have some thoughts (and possible mockups) around this. Would you mind sharing? I know my mockups can use a lot of help. 😉

[enriquesanchez]

👋 Hey everyone!

My explorations were very similar to the ones already shared:

While I think that having the label below the icon would scale better and should prove to be easier to work with on smaller viewports, I also share @afercia 's concerns about the labels being too long when translated to different languages. To give an idea of how much more space some labels will need, here's a side by side comparison of the toolbar in english and spanish:

I assume we might be able to work around this issue by tweaking some media queries, but I'm not sure if this is something that can be done based on what language the UI is set to 🤔

[afercia]

concerns about the labels being too long

Yep. Just noting that on some smartphone UIs, where the pattern with labels below the icons is not unusual, there are clearly strict rules about the length of the labels. Of course, that's possible because the mobile UIs are a very controlled environment but maybe worth exploring some rules to keep the Gutenberg labels as short as possible.

[tomjn]

It might be worth accounting for the eventual case where they do overflow. When firefox has more tabs than it can render, it adds arrow buttons and allows them to be scrolled. What happens at the moment if the buttons don't fit?

edit:

[afercia]

For inspiration, here's the previous android UI example in different languages (it's from my smartphone Gallery screen):

English:

Spanish:

French:

German:

Italian:

On one hand, it seems there are some length rules, for example:

• Spanish: "deselec" seems to me a truncated word (anyone can confirm?)
• Italian: "Deseleziona" omits "tutto" because it would be too long. On other screen with more room I've seen it's "Deseleziona tutto"
• German: not sure about "Abwählen": any German speaker here?

On the other hand, there seem to be an inconsistency in French:

• "Désélectionner tout" is very long and goes in two lines

Regardless of the small inconsistencies, it seems to me the various translations are crafted to respect a maximum length. Wondering if the Gutenberg UI should have a sort of "style guide" for translations.

[tomjn]

As an update, a quick way to add the labels in the browser is via this CSS:

.edit-post-header button::after {
    content: attr(aria-label);
    margin-left: 0.5em;
}

This results in the labels appearing to the right with a small amount of margin that can then be experimented with easily

[afercia]

Note: do not use the above CSS in production 🙂as it does impact accessibility (just to prevent people reading this issue from copying / pasting and use it on live sites! Excellent for testing purposes.)

[Luciaisacomputer]

@afercia thanks for the example, I don't have much internationalization experience so this gives me some new information that I hadn't encountered before!

[afercia]

@LukePettway thanks! I'm just trying to explore and learn new things 🙂

[enriquesanchez]

Spanish: "deselec" seems to me a truncated word (anyone can confirm?)

@afercia I believe you're correct. I assume it should be "Deseleccionar todo".

Wondering if the Gutenberg UI should have a sort of "style guide" for translations

I think this is an interesting idea. One option could be to allow the use of differnet words that may not be a direct translation from english but that have the same or similiar meaning. A quick example: I think we can use "Indice" (spanish for "Index") instead of "Estructura del Contenido" (spanish for Content Structure").

[afercia]

Thanks @enriquesanchez ! Yep, I think the most important thing for translation guidelines in these cases would be to clearly indicate to translators a strict length limit for some strings.

[mapk]

This was talked about in today's Design triage on slack.

When thinking through translations this gets really complex.

Side-by-side icon & label

PROS

• It looks pretty slick and keeps an evenly distributed space between each item's label and next icon.

CONS

• Long words may not fit in the spacing provided.

Icon on top of label

PROS

• The text can stack, or be hyphenated.

CONS

• The toolbar becomes more visually prominent and takes more space.
• Long words can still cause an issue with spacing.
• The icons with longer labels begin to be spaced visually awkward in comparison with the other items.

---

Are there other solutions regarding longer text?

1. Limit the strings for translations as @afercia noted above.
2. Automatically detect the amount of space and if items are not fitting, start pushing them into a dropdown.
3. Other ideas?

[mapk]

I think we can begin development on this and make any iterations in a PR.

1. Add the option to toggle this setting as stated in this comment above.

2. Stack the icons with labels below as in @enriquesanchez's mockups.

[enriquesanchez]

Hey @nicolad! Sorry for the late response, I was out on vacation and I'm slowly catching up.

To clarify, this means every single button that currently has no label will have one? Including those on the block toolbar?

[karmatosed]

I know there is thought against adding as accessibility option but with #16354, I feel it maybe works?

[haszari]

Does this issue cover block toolbars also? These are visual-only at present.

[mapk]

@haszari I think the individual block toolbars should be a separate PR that can pull from the learnings when this PR gets merged.

[tellthemachines]

Would it be worth exploring replacing the icons with labels, instead of just adding labels to the existing icons? Seems like this could help with some of the issues around space on smaller screens.

[ZebulanStanphill]

I've seen some apps have all 3 choices: text only, text + icon, and icon only. Perhaps we should do the same?

I do think that running out of space for toolbar options is inevitable no matter what we do. We have to figure out how to handle that situation when it happens. I'd say just move stuff into the ellipsis menu as necessary, with the stuff on the right being moved into it first. If that causes important actions to get folded into the menu too early, then maybe those actions shouldn't be there in the first place.

I know there have been some accessibility concerns about placing the save/publish actions in the top bar in the first place. Perhaps this is a good time to rethink how we organize controls. Why do we have a left half and a right half of the top bar? Why does the Top Toolbar option stick the block toolbar in the middle of the top toolbar? For ideal accessibility, controls should be laid out in a logical order that makes sense. I think a lot of the problems we're running into are a result of the top toolbar being weirdly laid out.

[mapk]

Would it be worth exploring replacing the icons with labels, instead of just adding labels to the existing icons? Seems like this could help with some of the issues around space on smaller screens.

@tellthemachines it looks like @jasmussen explored that here: #15830 (comment)

I like that solution, myself. 👍

I edited the link as noted by @ZebulanStanphill below.

[ZebulanStanphill]

@mapk I think the link in your comment is pointing to the wrong thing.

[jasmussen]

For what it's worth, I mostly explored the text only solution to leave no stone unturned. I am leaning more towards #15830 (comment) as the best approach. And I believe the most important step towards that (but a step that would benefit regardless of the approach), is to rephrase some of the very long labels into something smaller. "More tools & options" comes to mind as something that could be reduced.

[afercia]

rephrase some of the very long labels into something smaller. "More tools & options" comes to mind as something that could be reduced.

I'd agree. Although there's the need to differentiate the various "More" buttons. Also, when it comes to translations, worth reminding a previous comment:

Regardless of the small inconsistencies, it seems to me the various translations (note: on other apps) are crafted to respect a maximum length. Wondering if the Gutenberg UI should have a sort of "style guide" for translations.

At the very least, a maximum length should be recommended in a translator comment or by other means. I'd tend to think a real "style guide" for translators, with screenshots of the UI and detailed recommendations, would be even better.

[tellthemachines]

For what it's worth, I mostly explored the text only solution to leave no stone unturned. I am leaning more towards #15830 (comment) as the best approach.

I'm currently exploring a text-only solution for the top toolbar in #24304 , and it works well in that area, but I'm not fully convinced it'll work as well in the block toolbar, especially with the text formatting tools. Perhaps I'll give it a try with the icons. Would it be useful to have both as an option?

At the very least, a maximum length should be recommended in a translator comment or by other means.

I'll add some comments in. What would be a good maximum length here?

[mapk]

I am leaning more towards #15830 (comment) as the best approach.

@jasmussen, I've prepared some iterations and can use some feedback: #24304 (comment)

My Figma file has many smaller iterations on various parts of the topbar if you wanted to see those.

[jasmussen]

I don't want to block anyone from moving forward, to be clear! Any first baseline seems a good place to start, and there's no reason we can't iterate from there. Blaze a trail!

[afercia]

What would be a good maximum length here?

I think this is mostly a design decision on whether to allow the buttons to take more space )increase the width) when necessary or not. I'd suggest to switch the user language and check "live" with the PR you're working on how the toolbar would look with such languages. Amongst the European languages, the ones that typically have longer strings are German, French, and also Spanish and Italian. That could give a better idea of the problem that needs to be solved 🙂