-
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
Editor options have confusing highlighting #3733
Comments
The first item is a focus highlight to indicate what action is invoked when you press "enter". In my understanding, accessibility guidelines suggest that when a dropdown menu is opened, the first item has focus. We've had a discussion in the past on whether this focus should be visible, lingering there, even if you're not using the keyboard to invoke things (see this codepen for gory details), but the concensus from the WordPress accessibility team seems to be that this is intended behavior. @afercia can you chime in? |
I'm all for making things accessible and having focus styles, but the way this is currently styled, it looks like it's actually selected, rather than a menu item that just has focus. You could easily keep the focus indicator whilst at the same time, not make it look like it's selected, by having a dotted border and removing the background colour. |
Here's how that style could look: I don't dislike that, but I want to make sure with @afercia whether this is accessible or not. |
The dotted border color seems too light to me, it should have a sufficient color contrast. There's no point in (correctly) using a shape as focus indicator if then the shape can't be easily distinguished from the background color. A more generic consideration is that the Visual / Code choice would be a perfect case for 2 radio buttons. It's a single choice option: the native control for that are radio buttons 🙂 Not sure reinventing the wheel and using buttons for visual purposes it's so ideal. |
I like the idea of changing that Visual/Code Editor option to a radio button to make it more obvious which one is selected. Also, if that border colour is too light, or doesn't have enough contrast, how about just changing the colour of it. I still think that just the border alone makes a better option than having the whole background coloured, along with a border, as that makes the option look like it's been selected, rather than just having focus. Of course though, it's pointless if no-one can see it. Here's the same styles but using a blue border instead. I've used the same blue as the (Update) button. And here's an alternate option with a Dashed border instead of Dotted. |
That's not a hill I want to die on, so I won't block efforts in that direction. However I'd like to present a quick argument for why they look like they look right now, which is inspired by how menus in Google Docs work (look for line-height). In my mind, radio groups are visible both before the click, and after the click, essentially the point being that you can see the dot is now in a different inset ring, compounding the group aspect. In this case, picking an item in the menu immediately selects it, which in my head makes the checkmark feel more natural. Same argument for why it can make sense to use a Switch component instead of a checkbox — the switch saves the change immediately, whereas the checkbox should be accompanied with a "Save Changes" or "Apply" button. |
Well, looking at their implementation, the whole line-height menu is an ARIA menu: this way, their checked / unchecked state is reported correctly: Apart from the visual presentation, if you really want to build custom controls that are non-native in HTML, then semantics and interaction should be properly rebuilt using ARIA because this is the only way other software can understand what's going on. And this is what Google Docs does. |
@jasmussen Does #4512 actually address the concerns that I specifically raised in this issue? It doesn't appear to. As of Gutenberg 2.0.0, the way the Visual/Code Editor option is highlighted is still extremely confusing. |
Thanks for the pic. I'll retest this once a new version of the plugin is released |
Issue Overview
After clicking on the More icon and switching to Code Editor, I then clicked on the More icon again and based on the highlighting of the options, I have no idea what view I'm in. Am I in the Visual Editor, because it's highlighted and looks like it's selected, or am I in the Code Editor because it has a tick next to it, even though it doesn't appear to be highlighted like the other option.
Steps to Reproduce (for bugs)
Expected Behavior
I should be able to determine at a quick glance, which item is selected.
Current Behavior
The choice for highlighting the selected option is confusing
Possible Solution
Don't put a background colour and border around the option which isn't actually selected
Related Issues and/or PRs
#3708
Firefox Quantum 57.0
Gutenberg Version 1.8.1
macOS Sierra 10.12.1
The text was updated successfully, but these errors were encountered: