Gutenberg: Button active and focus state needs more distinct styling

[ellatrix]

Why? Accessibility. Some people don't see well. 👓

The contrast difference between active state and normal state is not big enough. Ideally it needs something like a border, inverted colours, underline...

http://webaim.org/resources/contrastchecker/

This is the style in core:

[mapk]

Current view of hover state:

Proposed revision:
I know there was discussion about the UI being _heavy_, so I tried to keep this as light as possible. I'm basing it all from the sketch file.

The contrast on the active states is compliant for WCAG 2 AA (18pt+). Does that work in relation to our icons there?

[ellatrix]

Trying something as well:

http://webaim.org/resources/contrastchecker/?fcolor=12181e&bcolor=e0e5e9

[ellatrix]

[ellatrix]

_Maybe_ contrast between two backgrounds is allowed to we smaller though, worth checking.

[afercia]

Contrast ratio can be just 3:1 instead of the usual 4.5:1 for "Large-scale" text, which is text "with at least 18 point or 14 point bold or font size". I'm not sure how to apply this to svg icons :) THey look bold to me, not sure about the font-size.

Adding a shape, even a subtle one, can surely help.

Just as a reminder: controls need also a focus style.

[ellatrix]

The contrast between the white background and the grey background is 1.27:1.

[afercia]

Ah well that. The difference between the two states should be perceivable. That reminds me of https://core.trac.wordpress.org/ticket/28599 where our recommendation is to use an additional indicator, like a shape.

[afercia]

Reference about font-size for contrast ratio:
https://www.w3.org/TR/WCAG20-TECHS/G18.html

The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.

Still not clear how to apply that to svg icons 😬

[mapk]

I believe the svg icons are 24px, so we should be ok. But the lighter grey against the white non-active state is still an issue.

[afercia]

Well, the icons rect is 24px. The glyphs inside the rect are smaller :) But as long as they're bold and they don't go under a corresponding font-size of 18.5px they should be ok.

[ellatrix]

The issue is not really the contrast between the icons and the background. That is 👌. The issue's the difference between the normal and active state, the white and light grey background. Which may be enough, I'm not entirely sure about that.

The difference between the two states should be perceivable. That reminds me of https://core.trac.wordpress.org/ticket/28599 where our recommendation is to use an additional indicator, like a shape.

So it sound like an extra indicator is good, but it hard to know what contrast between backgrounds is actually enough.

[jasmussen]

Good explorations so far. Keep the thoughts coming.

Let's expand our minds, as Ella suggests, and think beyond just _color_ as something that can add contrast. Some other ideas:

Neither of 👆 feel juuust right to me, but we're making progress here. @mapk importantly noted that the blocks were mentioned as feeling _heavy_, and as soon as we lightened the block borders and used the light white floaty chrome everywhere, the critique subsided. This is important to keep in mind, so we don't regress here.

We have to find a balance between the light UI and proper accessability, and we are on the cusp of it. Keep thinking folks! 🌟 work so far.

[jasmussen]

Also — this is a UI that has been solved in the past. Let's look at what others have been doing, like Google Docs, Word, Pages, Keynote, any other app or web-app that uses formatting controls like this.

[jasmussen]

Here's yet another attempt, which still doesn't feel right, but hopefully inspires more experiments:

[ellatrix]

Also — this is a UI that has been solved in the past. Let's look at what others have been doing, like Google Docs, Word, Pages, Keynote, any other app or web-app that uses formatting controls like this.

And WordPress 😉

_Google Docs_ ^

_Apple Pages_ ^

[ellatrix]

Anyway, let's not dig too deep into this issue, there are larger problems to solve. :)

[jasmussen]

The old TinyMCE look is very dated at this point, and very heavy looking. This on its own is not a reason to change it, but since we are doing a lot of modernization elsewhere in the UI, the time to modernize is now, make sure it fits the "language" of the rest of the optimizations we are making.

The splash of color that Pages adds seems worth exploring! There's a lot of gray in the UI already. The best color person I know in the whole world is @hugobaeta — if I may borrow a minute of your time (please ❤️ ) — is this a place where we can introduce an accent color to the default blue? I know you have some accent colors in your codepen...

[jasmussen]

More inspiration. Note, my posting these is not an endorsement — some of these are terrible.

Here's what Adobe Spark does:

Here's what Dropbox Paper does:

Here's what Facebook notes does:

Here's what Google Sites does:

Here's what LivingDocs does:

This is what Medium does:

This is what notion does:

Quip:

Squarespace:

Weebly:

Wix, sort of:

[melchoyce]

Some more ideas:

[afercia]

Inversion of colors ^^ could help :) Noting the active state should be clear for all controls, so maybe this issue should be extended to other parts of the UI?

[jasmussen]

Quick attempt at color inversion:

Feels like it's getting a little busy. But let's keep thinking about this.

[jasmussen]

Another shot at contrast:

This one looks good to me. The gray is a little darker, but the UI still feels light. The white boundary around the active one adds contrast too.

[melchoyce]

That last one's a winner.

[afercia]

I'm sorry to bring bad news 😬 but can't be done with color alone, especially it the difference between non-active/active is so light. It needs an additional indicator, e.g. a shape.

[ellatrix]

Also wanted to point out that the white border doesn't make a difference here. :/

[melchoyce]

Would a box shadow inside the selected button count?

[mapk]

The white boundaries around the active states works really well. My only concern is the contrast between the grey background on active states (I realize its darker) and the white background of the toolbar. In the last one posted by @jasmussen its contrast ration is 1.21.

Really good work.

[afercia]

I see this issue as very similar to the one discussed for the admin menu in https://core.trac.wordpress.org/ticket/28599 (still to be solved).
From an accessibility perspective there was consensus to add a border (actually a box-shadow) and recently the same pattern was introduced in the Customizer. Not to mention Press This always used that "border".
Not saying the same "border" should be added here, but the active state is a relevant information that shouldn't rely on color alone. Really needs a shape :)

[Afraithe]

Our theory here on the TinyMCE side of things is we want our UI to be skinnable, so we could add a high contrast skin. TinyMCE 3.x had that, haven't really had the need for it for TinyMCE 4, but 4 is also skinnable so perhaps ppl are using custom skins for that already. http://skin.tinymce.com/

[hugobaeta]

Looks like the experiment with the color inversion solves both issues (contrast, and shape). Maybe an ever so slight rounding of the corners of the selected elements would help in softening them?

[jasmussen]

Thank you @afercia for the context, I hope you'll continue to keep us on our accessibility toes! The core tickets help too.

Could a splash of color like this work?

This still keeps it visually light, and if we use that shade of blue elsewhere it could be visually coherent also. You mention that "color alone" is not enough — can you elaborate? Does it have to be

Alternately we should probably do what Hugo suggests and go full on inversion.

Here's a sketch file just with this piece, for quick iteration: https://cloudup.com/czgnRr9c4P2

[TheSpyder]

To throw another idea into the pool: what we've ended up with in https://textbox.io is a border on hover, switching to filled on active. It means you don't get a distinct "hover+active" state but we think it works quite well.

This also worked really well for windows high contrast mode where the background colour is ignored; it's still easily usable.

[jasmussen]

To throw another idea into the pool: what we've ended up with in https://textbox.io is a border on hover, switching to filled on active. It means you don't get a distinct "hover+active" state but we think it works quite well.

Screenshots, active:

Hover:

I like this a lot.

But is it sufficient with regards to contrast, @afercia? Also, can you refer to any editors with formatting toolbars you've used that pass the WordPress contrast standards? I'd like to look at a few for inspiration. As a reminder, here are a bunch of screenshots.

[afercia]

can you refer to any editors with formatting toolbars you've used that pass the WordPress contrast standards

I'm not sure I've used so many editors :) Many of them use a shape, or a combination of background color + shape (e.g. TinyMCE) so they pass the requirement.

As for the spec, the WCAG don't mention the "active" state (or at least I haven't been able to find anything specifically related to it) but have a lot of recommendations about the focus state, which we should take care of anyways. We can extend what it's recommended for the focus state to the active state too.

Understanding the "Focus visible" requirement:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

Specifically, about colors, see Example 3: Menus:
https://www.w3.org/TR/WCAG20-TECHS/G195.html

... the currently focused menu item changes its background to a different color, which has a 3:1 contrast ratio with the surrouding [sic] items and a 4.5:1 contrast ratio with its own text.

So, if you want to use only color, the active/focused button background should have a contrast ratio of at least 3:1 with the other buttons. Otherwise, it needs an additional indicator, like a shape.

I'd say the current implementation in WordPress passes the requirement because it uses a shape (rounded border) together with a slight background color change (which wouldn't be sufficient alone).

In the screenshot above, the Bold button is focused and the Italic one is active. Both slightly change the background color but that alone wouldn't be sufficient. Luckily, there's a border. If the new editor is going to have an implementation that doesn't allow to clearly distinguish the different states, I'd consider that an accessibility regression.

I'd encourage everyone to make a little effort and try to change the usual approach to design. There are accessibility requirements to satisfy. When designing with accessibility in mind, "design" should have a broader meaning: solving issues and yes, also try to make things look pretty as much as possible :)

[afercia]

To throw another idea into the pool: what we've ended up with in https://textbox.io is a border on hover, switching to filled on active.

@TheSpyder interesting. Aside: I love how in textbox.io all the controls are properly grouped and the toolbars are properly labeled :)

[jasmussen]

Thank you @afercia, this is very helpful.

I'd say the current implementation in WordPress passes the requirement because it uses a shape (rounded border) together with a slight background color change (which wouldn't be sufficient alone).

This was the 🔑 bit of clarity needed. The high contrast border ensures that the button (as a whole) has sufficient contrast with the surrounding items.

I got the vibe from the previous core trac ticket that the current core-bundled TinyMCE (as shown in your screenshots) did not solve the accessibility requirements, which made me confused.

Incidentally here's another shot at the color inversion:

[Afraithe]

Ppl that have contrast issues should be running their OS in contrast mode? So needs to work in that setting more than anything right?

[jasmussen]

Ppl that have contrast issues should be running their OS in contrast mode? So needs to work in that setting more than anything right?

Can we detect that OS level setting inside TinyMCE?

[afercia]

Ppl that have contrast issues should be running their OS in contrast mode?

Our goal here should be making it accessible out of the box.

[TheSpyder]

@afercia thanks! We have put a lot of effort into making sure the editor passes ainspector validation, including all dialogs ;)

@Afraithe the standards have contrast requirements even when not running in high contrast mode :(

@jasmussen you can, we have detection in textbox.io to activate our high contrast stylesheet. Chrome has an easy way to do it, other browsers need a bit of CSS trickery to detect that the browser isn't rendering backgrounds.

[jasmussen]

@afercia I'm digging the active/inactive design that Sketch uses:

Would this design pass accessibility requirements? If no, why not? Thanks much for letting me ask you these questions.

[joyously]

@jasmussen When I first saw that, my eye went to the larger boxes and I thought brighter meant selected (or active). Then I looked at the smaller ones and realized it was the other way around. I see this kind of confusion on a lot of mobile apps that just have a toggle. It's difficult to tell which way it is set to.

[afercia]

@jasmussen it's simple :) there are several tools to pick colors and calculate the contrast ratio. We often refer, improperly, to "color contrast" but actually it's about the luminosity contrast ratio.

About Sketch, pick the color of the active and inactive buttons, they're white and approximately #e5e5e5 right? For quick checks I often use this online tool our friend Joe Dolson made available for us: https://www.joedolson.com/tools/color-contrast.php

Enter the two colors and the ratio is 1.26:1. Instead, it must be at least 3:1, unless we're going to use some additional indicator to distinguish the different states.

Additionally, the contrast between the buttons text (icons) and their background must always be at least 4.5:1. Only for text with a font size of at least 18 point or 14 point bold (equivalent to approximately 24px and 18.5px bold) the minimum contrast ratio is 3:1.

[anna-harrison]

Great discussion with some really interesting insights, which I think distill down to three (+1) key points:

1. Accessibility should be designed into the product from the start, not added in later
2. It's quite challenging to meet accessibility requirements using colour alone - especially in the context of wanting a "light and modern" aesthetic
3. If colour alone is not enough, we need to use something else - like shape
4. [optional bonus] The interaction is a little fun :)

So today we had a crack at playing around with something that meets the above criteria: you can interact with it here http://codepen.io/napy84/pen/LWbBrv

It's possibly too much/not the right kind of animation ( discussion on animation style guide here #15 ) to be used on every button, but perhaps if used selectively, like on the block level controls, could be both elegant and provide differentiation from the [selection]-toolbars

[jasmussen]

Thank you for your endless patience here, @afercia. This is important to get right. It sounds like the following would pass:

But by those rules put out alone it sounds like Google Docs, Office 365, Apple Pages, Sketch would all fail:

That last one is Apple Pages, which achieves a 2.6:1 contrast ratio, the most of them all. But it's still not 3:1.

Can you confirm that all those above fail the accessibility bar, or do they pass through other means? If so, what makes them pass? You mention:

unless we're going to use some additional indicator to distinguish the different states

To me this sounds like a border, or an inset shadow on the active item. But in all of those above, the border itself does not have enough contrast either. Is it the very dark border around the active item in current TinyMCE that makes the current iteration of the editor pass?

I am very grateful for your time here.

[ellatrix]

Is it the very dark border around the active item in current TinyMCE that makes the current iteration of the editor pass?

Yes, it is. :) Here's the most recent commit for that: https://github.com/WordPress/wordpress-develop/commit/e9f19035864e432453ff0978eaa5a6379ccdc6c5

Would be good to know which others pass or not. It sounds like inverse colours make it so that appearance is distinct enough from the other buttons.

Even if the others do _not_ pass, it doesn't mean our editor shouldn't, and this is a great area where the WordPress editor can shine, together with all the other improvements we're doing. Like @afercia mentioned, it's a really interesting design challenge, where alternative creative solutions are welcome. Maybe there's a whole new way to design active states. :)

[jasmussen]

Even if the others do not pass, it doesn't mean our editor shouldn't

Absolutely, did not mean to imply otherwise. 😉

[Afraithe]

Googles Material Design could also be a source of inspiration around this I guess.

https://material.io/guidelines/components/buttons.html

[jasmussen]

How's this?

That's a 4.8:1 on the contrasts, as far as I can tell.

[mapk]

According to @afercia:

Enter the two colors and the ratio is 1.26:1. Instead, it must be at least 3:1, unless we're going to use some additional indicator to distinguish the different states.

So that means this ones fails:

Luminosity Contrast is 1.46:1

The gradient in this one might be a bit more tricky?

Lighter top Lum Contrast is 2.15:1
Darker bottom Lum Contrast is 3.1:1
But it's also inverting the color, which is more than just changing the background.

I do like this one below the best. But we still need a HOVER state designed.

Maybe something like this?

[afercia]

I think the one with the subtle dark border, the last one posted by @jasmussen would pass 🙂 Also the last one by @mapk 🙂

by those rules put out alone it sounds like Google Docs, Office 365, Apple Pages, Sketch would all fail

I'm really not sure what are their accessibility requirements 🙂

it's a really interesting design challenge, where alternative creative solutions are welcome. Maybe there's a whole new way to design active states. :)

Yay! +1

[TheSpyder]

There's a tool to help you know if it passes - a Firefox addon called ainspector. It will likely complain about a lot more than contrast, but if you're diving into accessibility that's a good tool to use in general. It's very picky but so are the standards 😉

The last one by @mapk is what we do in textbox.io which definitely passes.

[jasmussen]

Closing as this is solved by the inverted version in the mockups: https://wpcoredesign.mystagingwebsite.com/gutenberg/

Feel free to reopen if this issue surfaces again.