Editor options have confusing highlighting

[maddisondesigns]

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)

1. Click on the 3 vertical dot icon in the top right-hand corner when editing content
2. Switch to Code Editor
3. Click on the 3 vertical dot icon again

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

[jasmussen]

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?

[maddisondesigns]

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.

[jasmussen]

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.

[afercia]

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.
Also, there's no semantic indication about which of the 2 buttons is currently selected. Radio buttons would communicate this information natively.

[maddisondesigns]

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.

[jasmussen]

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.
Also, there's no semantic indication about which of the 2 buttons is currently selected. Radio buttons would communicate this information natively.

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.

[jasmussen]

Here's a version of the focus outlines that uses $gray-dark-900, the darkest we have before black:

[afercia]

which is inspired by how menus in Google Docs work (look for line-height).

Well, looking at their implementation, the whole line-height menu is an ARIA menu:
role="menu" aria-haspopup="true"
and each item is a menuitemcheckbox:
role="menuitemcheckbox" aria-checked="true"

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.
Native radio buttons would give all of this for free, out of the box. If we're able to build a proper ARIA menu with proper roles and properties, then I'm all for it.

[maddisondesigns]

@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.

[jasmussen]

I don't believe 4512 reached 2.0 in time for release. But this is how master looks:

[maddisondesigns]

Thanks for the pic. I'll retest this once a new version of the plugin is released