Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Icons alone are visible for controls unless they are hovered or focussed #15311

Open
karlgroves opened this issue Apr 30, 2019 · 9 comments
Open
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@karlgroves
Copy link

Icons alone are visible for controls unless they are hovered or focussed

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

Issue description

Throughout the editor, large icons denote the meaning of controls
visually. The buttons have programmatically accessible names, and these
names (and their keyboard shortcuts if any) can be made visible by
hovering with the mouse or moving keyboard focus to them.

However hovering is an action that cannot be performed on most touch
devices, and moving keyboard focus generally requires a keyboard (or
something imitating it such as Switch Control). This leaves speech
recognition users (who rely on knowing the name of a control for the
easiest activation) in the position of needing to manually get focus to
the page and then using "press tab" to move focus to each control to
see (and memorise) the name for later use, or using the more cumbersome
Mouse Grid to slowly move the mouse to the desired control.

Touchscreen users with cognitive disabilities have no easy way to learn
what controls are going to do before they interact with them.

Remediation Guidance

One solution would be to provide users with a setting, which shows
labels in place of (or as well as) icons, similar to Gmail's settings.
An example of this can be see at:
https://allenpike.com/images/2019/lukew-translate.jpg

This setting would allow users who prefer icons-only to continue to work
with icons only, while those who prefer or require text labels would
have that option too.

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-66 in Tenon's report

@gziolo gziolo added the Needs Accessibility Feedback Need input from accessibility label Apr 30, 2019
@afercia
Copy link
Contributor

afercia commented May 1, 2019

+1 ! As mentioned several times and also in the Gutenberg accessibility report published on November October 2018, icon-only controls are an accessibility anti-pattern, period. See https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/

Only concrete proposal so far is related just to the top toolbar, see #10524. No PR so far.

@afercia afercia added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed Needs Accessibility Feedback Need input from accessibility labels May 1, 2019
@afercia
Copy link
Contributor

afercia commented May 2, 2019

For quicker reference, here's the image mentioned in the summary:

lukew-translate

@melchoyce
Copy link
Contributor

Screenshot from the full report:

image

@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label May 6, 2019
@mapk
Copy link
Contributor

mapk commented May 7, 2019

Let's get issue #10524 into a PR. This will help a good portion of this. Once that is solved, we can continue on the block toolbar icons as well.

Some thoughts around the block toolbar icons were shared in the slack design triage today by @draganescu. Andrei mentioned a possible solution for the toolbar is that when labels are turned on, the block toolbar gets moved to the top toolbar. Any thoughts around this?

Screen Shot 2019-05-07 at 9 16 27 AM

@tellthemachines
Copy link
Contributor

I had a quick go at adding labels to all the icon-only buttons in the post editor; here are some screenshots!

Top toolbar (there's plenty of discussion about it already in #15830 )
Screen Shot 2020-07-29 at 4 07 30 pm

Top toolbar with block toolbar attached:

Screen Shot 2020-07-29 at 4 13 46 pm

Block toolbar:

Screen Shot 2020-07-29 at 4 03 31 pm

Block placeholder:

Screen Shot 2020-07-29 at 4 05 15 pm

Add block icon:

Screen Shot 2020-07-29 at 4 04 30 pm

Close settings:

Screen Shot 2020-07-29 at 4 07 11 pm

We may not want to add labels to all of these buttons; e.g. the close button seems pretty self-explanatory. But for most of these cases we'll be needing some design input 😄 cc. @mapk

@mapk
Copy link
Contributor

mapk commented Jul 29, 2020

Because this includes so much, can we break it down a bit into different PRs? Like one PR to address the top toolbar, another PR to address the block toolbars, etc.

Looks like we do indeed have some design work. I'll give this another go.

@tellthemachines
Copy link
Contributor

Because this includes so much, can we break it down a bit into different PRs? Like one PR to address the top toolbar, another PR to address the block toolbars, etc.

Sure! That's my plan 😄
I've started already with #24234 to add the option itself, and am now working on the top toolbar based on the designs shared in #15830 .

@noisysocks
Copy link
Member

We're using icon-only controls for the block appender (the ➕ button) in both the post editor and widget editor, too. Let's please include these buttons as part of an option to show text labels.

Post editor:

Screen Shot 2020-10-02 at 11 39 22

Widgets editor:

Screen Shot 2020-10-02 at 11 41 27

@afercia
Copy link
Contributor

afercia commented Oct 5, 2020

The consideration about the + button in the Widgets screen comes from #24939 where it was noted the Widgets screen is a new feature that will land in WordPress 5.6. As such, the fix for the Widgets screen should be included in the things to have for 5.6 and I'm not sure this issue is appropriate.

As I see it, this issue is more a "tracking" issue and specific cases should maybe be addressed on specific issues. I'm saying this because I'm not sure we should use the same component for the + button in the Widgets and in the block editor.

A user preference as proposed in #15311 (comment) is certainly an option but it's different from having the button text visible by default as asked in #24939. Will ask the accessibility team to evaluate the proposal during the next meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

No branches or pull requests

10 participants