-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
+1 ! As mentioned several times and also in the Gutenberg accessibility report published on Only concrete proposal so far is related just to the top toolbar, see #10524. No PR so far. |
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? |
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 ) Top toolbar with block toolbar attached: Block toolbar: Block placeholder: Add block icon: Close settings: 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 |
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. |
Sure! That's my plan 😄 |
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. |
Icons alone are visible for controls unless they are hovered or focussed
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
The text was updated successfully, but these errors were encountered: