Media Editor: Visible labels are not available on editing buttons

[afercia]

Moved from the ​WPCampus accessibility report issues on GitHub, see ​https://github.com/WordPress/gutenberg/issues/15352

Visible labels are not available on editing buttons

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

#### Issue description

On the Edit Media page, buttons for editing the selected media image
have accessible names to label them for assistive technology users,
however these names are not available to sighted users.

Since some of the icons are quite cryptic, and there is an ambiguity
between two sets of icons which both appear to mean Rotate. This may be
confusing to users with cognitive disabilities. Such users may find
themselves having to interact with buttons just to figure out what they
do.

#### Remediation Guidance

Add visible text labels to the image editing buttons.

One method, which would be consistent with the rest of the editor, would
be to use keyboard-accessible tooltips for this.

A better method would be to provide a user setting for all icon
controls, so that users can specify whether to show icons-only,
labels-only, or icons and labels together.

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](​https://www.tenon.io) and funded by [WP Campus](​https://wpcampus.org/). This issue is GUT-85 in Tenon's report

[afercia]

The media editor buttons.

[afercia]

Related: #41634.

[nrqsnchz]

I've attached a patch that adds proper labels to the edit image button. This makes the row of buttons much longer, so I made the CSS changes necessary to have the row of buttons wrap as needed.

This is before the change:

After the change (wide viewport):

After the change (medium viewport):

After the change (small viewport):

---

Tested on Mac on Firefox, Safari and Chrome. Also tested with VoiceOver and Safari.

While this change makes these buttons more obvious and addresses the concerns raised on this ticket, I'm not sure I love how much more UI is added by the row of buttons when it wraps to two or three rows. I'd love to get opinions/ideas from others.

[nrqsnchz]

Patch that adds labels to the image edit buttons

[nrqsnchz]

Additionally, we could reduce the length of the buttons by replacing "Rotate counter-clockwise" to "Rotate left" and "Rotate clockwise" to "Rotate right".

[sabernhardt]

@nrqsnchz Quick edit to your patch: the label text will still need the PHP function to make sure the string is translatable, as it has been for each of those 7 labels:

<?php esc_html_e( 'Crop' ); ?>

Also, mainly because of the need to translate, I would not recommend changing the text label based on how long it is in English. It's probably even wider in another language.

[sabernhardt]

Below is a design concept that groups the buttons @nrqsnchz made and rearranges the order, and I'd like feedback to know whether this is an improvement before trying to create a new patch with it.

I'd want the rotate and flip options to remain on the same line as their counterparts, so this design combines each pair in floating fieldset/legend groups above the other 3 buttons (Crop, Undo and Redo).

.
Flip buttons drop below the Rotate buttons at 120 percent on my screen (or similarly on smaller screens without the zoom):

This layout would require 6 new translatable strings (and the current text strings could be re-purposed as ARIA labels for those 4 buttons).

[nrqsnchz]

The more I think about it, the more I don't think that having those options in the place where they currently are is ideal (if we want to also have labels).

It takes way too much space on small viewports and when the user zooms their browser. That last morkcup you shared @sabernhardt is a good example of what I mean.

I've been thinking about the possibility of having these buttons on the sidebar. We seem to have some related items in there already (Scale Image and Image Crop). So what if we grouped all of these together? (we can keep Undo and Redo in the same place)

The stuff that is currently in Scale Image and Image Crop can be revealed contextually. So, for example, if I click on Crop, the aspect ratio and selection settings can appear below it:

[afercia]

I'd agree the Media editor screen would need some rethinking. It will anyways because there's another ticket from the WPCampus report which points out the reading / focus order mismatch. See #47136 and the screenshot attached there.

Exploring how to group the UI controls in a more logical place as proposed by @nrqsnchz seems a good start to me.

[nrqsnchz]

#41634 was marked as a duplicate.

[afercia]

Discussed during today's accessibility bug-scrub. The idea to move the buttons sounds sensible. Agreed Undo and Redo should be moved as well and grouped with all the other editing controls. Otherwise, keyboard and screen reader users would have to traverse back and forth all the content to Undo / Redo / Edit.

Pending major re-ordering from #47136 and design feedback.

[anevins]

Hey @nrqsnchz, just checking if you're okay with owning this ticket?

[nrqsnchz]

Hey @anevins! Yes, I'm currently working on patch.

[nrqsnchz]

Here's a patch that addresses the following:

1. adds labels to the edit buttons
2. relocates the edit buttons group to the right sidebar, this was needed because the buttons with labels now take up more space and the previous position was not ideal for this.
3. small style tweaks to the edit tools buttons to have them match the style of secondary buttons in other places
4. adds an H2 (Editing Tools) to the group of edit buttons for easier navigation and findability.

Regarding the discussion above about the redundancy between the Crop tool and the Image Crop section: this patch does not address that. I think it's out of scope for now and addressing that issue requires a more thorough assessment of the information architecture of this view.

[nrqsnchz]

Quick fix that wraps the new "Editing tools" H2 in <?php _e( 'Editing Tools' ); ?> for internationalization.

[kirasong]

I'm working on 5.3 triage and came across this ticket. @nrqsnchz thank you so much for working on design for this ticket!

I'll see what attention I can get on the design in upcoming media conversations.

Due to the redesign, to me this is moving into enhancement territory rather than bug, so I'm wondering if it should stay in the 5.3 milestone or not.

What do y'all think?

cc: @afercia

[kirasong]

After chatting with @afercia about this in the Media channel, I concur this is a bug. Thanks @afercia for teaching me more about the anti-pattern involved, and apologies for not already knowing.

I remain a little hesitant about landing a redesign in beta, but let's see what feedback we can get on this ticket to move it forward, since I would love it if this could happen in 5.3. I'll message some folks.

[afercia]

Thanks @mikeschroder. I’d consider this ticket a bug, as the buttons without visible text are not operable by some users e.g. speech recognition software users.

Moreover, icons don't have a universal meaning. Generally, icon-only controls are an accessibility anti-pattern as the accessibility team outlined in other reports, for example in the Gutenberg accessibility report published on October 2018 ​https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/

[anevins]

The screenshot with the visible labels look so wonderfully helpful, thank you!

[karmatosed]

Wow, this ticket moved on a bit, thanks for all the work everyone. Whilst I am not going to counter the work done here, I would like to offer some design feedback. I want to do this to not block but have us consider in beta a few points.

First, the position in the sidebar I feel is problematic from a cognitive and action point of view. It's removing a direct interaction from where it happens. I understand why now because the buttons are just too vast, however just putting them in the sidebar I don't feel solves this as removes from where they made sense to be. The placing in the sidebar is what for me takes this from bug to enhancement, so I agree with @mikeschroder on that. I understand labels put it in a bug, but this ticket does both.

I have concerns over moving and what plugins hook into this. For example, if a plugin adds icons/buttons here do we end up having lots in the sidebar? That could be seriously problematic on smaller screen heights and in general cause a lot of problems.

For me, the moving to the sidebar is done without exploring where the best possible location should be. I would love to see exploration as to that. I wonder if they are even buttons anymore like this? Why can't we have buttons that have tooltips/explanations for example? What about exploring hiding interactions in a toolbar of sorts even a drop-down? If text is desirable, I am sure another option can be found.

My advice at this point would be to not move to the sidebar in this as that takes it to an enhancement. If a better option is found for placing during beta 1, we could evaluate then, but for now my feeling is the sidebar doesn't do that. I am not commenting on text being by icon, but placement.

I will note, we are all pushing against the limits of the current interface so I recognise wins are hard in this confined space. That said, I think we shouldn't move buttons and actions without considering their impact in such a fixed design. What for example in a small sidebar happens to that text in translations, with plugins hooking in? It's for these and interaction reasons I am recommending we don't move them this release.

[karmatosed]

Just a little update, @afercia and myself talked this through in Slack as beta is due today so wanted to not cause any holdups. The plan is to split this into 2 patches:

• Text additions to buttons.
• Moving of buttons to sidebar.

During beta 1 the following tests and explorations are needed:

• Test what (if any) plugins add buttons and the effects of that in sidebar.
• Test translations and what is stress case for those in limited width of sidebar.
• Explore what position could be other than sidebar.

[sabernhardt]

@nrqsnchz The moving_buttons_to_sidebar.diff​ patch still has "test" above the image.

[nrqsnchz]

Replying to sabernhardt:

@nrqsnchz The moving_buttons_to_sidebar.diff​ patch still has "test" above the image.

Whoops! Thanks @sabernhardt! Fixing now.

[nrqsnchz]

Properly removes "test" from patch :)

[nrqsnchz]

As requested, I've split these updates into two patches:

1. add_labels_to_buttons.diff

2. moving_buttons_to_sidebar_3.diff

[afercia]

If there are no objections, I'd like to commit add_labels_to_buttons.diff​ which just adds visible text to the buttons, as agreed with Media and Design team.

[afercia]

Additionally, we could reduce the length of the buttons by replacing "Rotate counter-clockwise" to "Rotate left" and "Rotate clockwise" to "Rotate right".

I'd totally agree because it's way more intuitive and shorter.

I'm going to change that and also make a few minor CSS adjustments. For example: we can't use overflow: auto on the buttons container because it cuts off the focus style of the buttons (see screenshot below).

[Edit]: the float and wp-clearfix are needed for the overlay and the spinner when the editor is running an edit.

[melchoyce]

​Tried a couple ideas and chatted it over some in Slack, and decided that keeping it simple is the way to go. I made a slightly modified mockup of add_labels_to_buttons.diff using shorter labels, and moving undo/redo to their own line.

[afercia]

47116.2.diff​ addresses the first part of this ticket, by making the buttons text visible as discussed today's on Slack.

• Some of the text are shortened: Rotate left, Rotate right, Flip vertical, Flip horizontal.
• Undo and Redo are always on their own line
• The patch also introduces some very basic responsiveness for the Image Editor page. Worth noting responsiveness of this page and of the Image Editor within the media modal has always been far from ideal and still breaks on small screens. This is just a first, small, improvement pending major redesign of the Image Editor.

See screenshots below.

[afercia]

@nrqsnchz thanks for your perseverance! As agreed with the Design team, I'm going to commit the first part of this issue. Would you mind moving the second part with your findings and screenshots to #47136? That's probably the best place to explore a major redesign of the Image Editor. Thanks!

[afercia]

In 46326:

Accessibility: Media: Make the Image Editor buttons text visible.

User interface controls that use only icons aren't ideal for many users.

Universal icons are rare. Icons must communicate meaning but their actual meaning varies depending on many factors including the users cultural background.
Moreover, users with cognitive impairments and speech recognition users need interface controls with visible text to be able to operate them.

• shortens some of the buttons text to: Rotate left, Rotate right, Flip vertical, Flip horizontal
• moves the Undo and Redo buttons underneath the main buttons group

Props nrqsnchz, melchoyce, karmatosed, sabernhardt, mikeschroder.
Fixes #47116.

[azaozz]

I know the image editor is in need of redoing/replacement and should probably be deprecated now, but [46326] seems to introduce a visual/CSS regression.

[afercia]

Hm the Image Editor has always had a less than ideal (to be fair) responsiveness since, forever. In 5.2.3 depending on may factors like: 1 or 2 columns layout, admin menu auto-folded / folded, image size, etc. most of the times at certain viewports widths there's a complete "float drop": the image just goes at the bottom of the page. See screenshots below taken on 5.2.3

What I'd like to outline is that it's already completely broken :) Not sure we can call this is a "regression" as the original behavior is already broken.

Anyways, I can easily restore the original float drop. Patch incoming.

Maybe the next release cycle will finally be a good opportunity for a major redesign of the Image Editor, as it's a very, very, old page and the layout issues make it barely usable on many devices.

[afercia]

47116.3.diff​ restores the original "float drop" layout.

[afercia]

In 46331:

Media: Restore the original Image Editor columns layout after [46326].

Fixes #47116.

[azaozz]

Yeah, this is still pretty bad but at least doesn't overlap... The UI there should be "fixed min width" as the preview image used in there is fixed width. Don't think this has ever worked well, lets perhaps look there again in 5.4. Ideally, of course, the whole image editor needs re-evaluating and replacing :)

[sabernhardt]

(You can ignore this comment. After paying more attention to details on this ticket, I posted a better comment on the more appropriate ticket #47136.)

To avoid having the panel drop below in two-column layout while the window is still rather large (my laptop screen at 1366 pixels wide), this could be added to the stylesheet:

.columns-2 .wp_attachment_holder .imgedit-wrap .imgedit-panel-content {
	max-width: calc(100% - 266px);
	min-width: 400px;
}

Would this need to be a separate ticket for 5.3 or could it be added another way?