Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#47118 closed defect (bug) (fixed)

Media Editor: Undo and Redo icons are not consistent throughout the interface

Reported by: afercia's profile afercia Owned by: audrasjb's profile audrasjb
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Media Keywords: wpcampus-report has-screenshots
Focuses: ui, accessibility Cc:


Moved from the WPCampus accessibility report issues on GitHub, see

Undo and Redo icons are not consistent throughout the interface

  • Severity: Low
  • Affected Populations:
    • Cognitively Impaired
  • Platform(s):
    • All / Universal
  • Components affected:
    • Edit Media

#### Issue description

On the Edit Media page, there are various icon buttons for performing
actions to the selected media image, along with "Undo" and "Redo"

These two buttons use different icons than the "Undo" and "Redo"
buttons in the Editor Top Bar.

Ideally these buttons' icons would be consistent with the ones in the
Editor Top Bar, especially since these icons look like Rotate icons
(causing the actual Rotate buttons to require more complex glyphs to
appear more clearly as Rotate-the-image), while the Editor Top Bar icons
do not look like Rotate buttons.

#### Remediation Guidance

Use the same icons for the "Undo" and "Redo" buttons as are used in
the Editor Top Bar.

#### Relevant standards

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by [Tenon]( and funded by [WP Campus]( This issue is GUT-84 in Tenon's report

Attachments (3)

47118.png (155.9 KB) - added by afercia 4 years ago.
Comparison of the Gutenberg icons in the Editor Toolbar and the icons in the Media Modal
Capture d’écran 2019-08-16 à 22.55.58.png (42.1 KB) - added by audrasjb 4 years ago.
Capture d’écran 2019-08-16 à 22.55.39.png (29.6 KB) - added by audrasjb 4 years ago.

Download all attachments as: .zip

Change History (19)

#1 @afercia
4 years ago

  • Keywords has-screenshots added

See also comments and screenshots by @kjellr and @melchoyce on the GitHub issue starting from

From a technical perspective, this implies introducing SVG icons in core, which uses only Dashicons so far. I guess there's large consensus about consistency.

4 years ago

Comparison of the Gutenberg icons in the Editor Toolbar and the icons in the Media Modal

#2 @afercia
4 years ago

  • Milestone changed from Future Release to 5.3

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

4 years ago

#4 @antpb
4 years ago

Hello! This was discussed in the recent Media meeting and we are clear on the issue but need to explore the functionality of these buttons further to understand their purpose. There is some discussion around the purpose of the buttons and wether or not they are the same. If the same, we should provide a more visually consistent button. If not, maybe the difference is justified and we just need to make them more different.

Also worth noting from @mikeschroder ’s initial digging, he found that “aria-label on the Gutenberg buttons are “Undo” and “Redo”
looks like a span with class of “screen-reader-text” of “Undo” and “Redo” in the image editor”

#5 @afercia
4 years ago

Re: aria-label vs. screen-reader-text

In Gutenberg, the buttons use aria-label also because their tooltips use the text from the aria-label. This allows to expose the buttons accessible name visually, both on hover and on focus.

In the media editor the buttons use screen-reader-text just because of historical reasons. The visually hidden text allows screen reader users to understand what the buttons are about.

However, these media editor buttons don't expose their names visually. This is a problem for sighted users who can only use the keyboard or a technology that mimics the keyboard. For example: speech recognition software (Dragon) users. They need to know what a UI control name is to be able to voice a command like, for example: "Click flip vertically".

Not to mention cognitive impairments or simply different cultural background or non-familiarity with icons. Controls that use only icons are problematic for many users. This issue was discussed at length in the Gutenberg project and still needs to be fully addressed.

Accessible tooltips would help but they still wouldn't solve the issue for speech recognition software users. Worth also reminding that the introduction of tooltips in core was discussed many years ago and there was no consensus.

Gutenberg uses tooltips though, so I guess it's time to start some new conversation to evaluate their introduction in core.

As said, they wouldn't be sufficient anyway: the UI should offer options to reveal the controls name, see this related issue on the Gutenberg GitHub:

This ticket was mentioned in Slack in #core-php by afragen. View the logs.

4 years ago

#7 @audrasjb
4 years ago

  • Owner set to audrasjb
  • Status changed from new to accepted

This ticket was mentioned in Slack in #core-media by anevins. View the logs.

4 years ago

#9 @audrasjb
4 years ago

I don't know how it happened but I have the same icons for undo and redo on my development installation!
See screenshot below: was it patched in another commit?

#10 @afercia
4 years ago

@desrosj @Joen when you have a chance: is this change related to / or any other recent change in the dashicons repo?

I couldn't find any mention of changes to the undo / redo icons in the related Trac ticket #41074.

#11 @audrasjb
4 years ago

  • Keywords close added

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

4 years ago

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

4 years ago

#14 @desrosj
4 years ago

  • Keywords close removed
  • Milestone 5.3 deleted
  • Resolution set to invalid
  • Status changed from accepted to closed

I believe that I spoke with @joen about this at one point and this was an intentional change.

It looks like this PR is responsible:

Let's close this out, and if I am remembering incorrectly, it can be reopened.

#15 @SergeyBiryukov
4 years ago

  • Milestone set to 5.3
  • Resolution changed from invalid to fixed

If the icons are consistent now, per comment:9, I would consider the ticket fixed, rather than invalid :)

#16 @desrosj
4 years ago

No opposition here. I only did invalid and removed the milestone because it was actually fixed in 5.2 through #41074. I also toyed with marking as a duplicate of that issue.

Note: See TracTickets for help on using tickets.