Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#36447 assigned enhancement

Responsive preview icons in Customizer need tooltips

Reported by: ahortin's profile ahortin Owned by: iamjolly's profile iamjolly
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6
Component: Customize Keywords: has-screenshots tooltips dev-feedback needs-patch
Focuses: accessibility Cc:


The new icons at the bottom of the Customizer for toggling the preview window of your site really need tooltips to indicate what they're for.

Just like the tooltips on the Visual Editor icons, other icons in the Dashboard should have tooltips as well. As leading usability expert Jakob Nielsen explains;

A user’s understanding of an icon is based on previous experience. Due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity.

Even the Google Design Guidelines recommend tooltips for icons

I originally raised this as a post on the Beta forum but it was suggested that since it's getting late in the 4.5 release cycle it would be best to raise it as a Trac ticket.

Attachments (3)

github-icons-hover-tooltip.png (13.1 KB) - added by iamjolly 8 years ago.
GitHub icons in hover state showing tooltip text
github-icons-focus-vo.png (51.2 KB) - added by iamjolly 8 years ago.
GitHub icons with focus showing tooltip and appropriate VoiceOver output for icon
36447.patch (2.0 KB) - added by Cheffheid 7 years ago.

Download all attachments as: .zip

Change History (19)

#1 @westonruter
8 years ago

  • Focuses accessibility added


I personally feel the tooltips would be helpful. The icons aren't totally clear what the buttons do. Here the accessible text is even more clear than the visual icons, I think. Here the visual users need an accessibility aid.

#2 @celloexpressions
8 years ago

Repeating my comment from Slack:

Because these buttons perform non-destructive actions that are visually obvious when clicked, I think the simplicity of not having tooltips is better. They would certainly become distracting once the user knows what the buttons do, and after using them a few times I would expect most users to remember their purpose. My only concern would be whether users try clicking them in the first place, and that could potentially be solved with a feature pointer or by the specific way it's highlighted on the about page.

I also wouldn't want to attach text to these as the specific buttons are intentionally ambiguous - the previewed sizes are arbitrary and not intended to represent specific devices, only provide a general idea of how the site behaves on different screen sizes.

If appropriately vague text labels could be found, we could look at doing this. I personally feel that the labels there for screen readers are a bit too specific (potentially mis-interpreted) already.

Full conversation:

#3 @ahortin
8 years ago

@celloexpressions the fact that they're non-destructive is irrelevant. People shouldn't have to click a button to find out what it does. That's the most annoying thing ever. Why is there a tooltip on the Distraction Free Writing icon in the Visual Editor? It's non-desctructive as well. By your way of thinking, this tooltip should be removed also.

You should know what an icon/button does BEFORE you click it. If I'm using an interface and I don't know what a particular button does, I'm less likely to click it at all, just in case it messes up my work. If I don't know what the icon/button does, how do I know if it's non-destructive?

Even though the sizes may be arbitrary, they'd still benefit from having labels like "Mobile view/Tablet view/Desktop view", or something along those lines. They're not device specific and will at least give people an idea of what the icon does.

Also, tooltips don't become distracting once you know what an icon/button does. I refer to the Visual Editor again. I don't find the tooltips on any of those buttons annoying and I've been using them for 10+ years. Once you know what an icon does, you simply click it and move on. Your mouse doesn't tend to hover over it. The tooltip will only display for a microsecond.

Last edited 8 years ago by ahortin (previous) (diff)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

8 years ago

#5 @rianrietveld
8 years ago

  • Keywords needs-screenshots added
  • Milestone changed from Awaiting Review to Future Release
  • Owner set to iamjolly
  • Status changed from new to assigned

Discussed this ticket in the wpa11y meeting:
Adding Tooltips seems like a good idea:
@iamjolly: I really like how GitHub does the icons with aria-label and tooltips.

8 years ago

GitHub icons in hover state showing tooltip text

8 years ago

GitHub icons with focus showing tooltip and appropriate VoiceOver output for icon

#6 @iamjolly
8 years ago

  • Keywords has-screenshots added; needs-screenshots removed

This ticket was mentioned in Slack in #accessibility by iamjolly. View the logs.

8 years ago

#8 @Cheffheid
7 years ago

  • Keywords ui-feedback added

Just to give this a bit of a push forward. I jacked some of the Github code and created a .tooltip class (limited to #customize-controls for now). Would definitely appreciate some design input on these things to help them match the admin look better.

One complication that I'm running into with these CSS-only tooltips is that when one of those buttons is clicked the tooltip sticks around. I think there are JS solutions to fix that (like, but I'm a bit too overwhelmed by the amount of Customizer JS to make that change properly.

Will add a patch with what I have so far, which adds the tooltip class CSS and adds the class to the device buttons.

7 years ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

6 years ago

#10 @afercia
6 years ago

  • Keywords tooltips added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 years ago

This ticket was mentioned in Slack in #design by joshuawold. View the logs.

5 years ago

#13 @JoshuaWold
5 years ago

We just discussed this in our #design triage. As long as the tooltips are created the same way as "tooltips" for the WordPress Gutenberg editor (with accessibility in mind), then it definitely makes sense to include in the Customizer.

Also, the text suggested seems to work well.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.

5 years ago

This ticket was mentioned in Slack in #design by chaion07. View the logs.

3 years ago

#16 @estelaris
3 years ago

  • Keywords dev-feedback needs-patch added; ui-feedback removed

This ticket has had design recommendations from 3 years ago. Can a developer please pick it up from here and add a patch with screenshots to see the patch working

Note: See TracTickets for help on using tickets.