Page MenuHomePhabricator

Improve color palette to comply with WCAG 2.0 min level AA and color-deficiency-friendly.
Closed, ResolvedPublic

Assigned To
Authored By
violetto
Aug 21 2015, 11:09 PM
Referenced Files
F4487514: Artboard M82 Color Palette 2016-09-19 (WCAG compliant).png
Sep 19 2016, 8:43 PM
F4404108: MediaWiki theme buttons 2016-08-26.png
Aug 26 2016, 11:19 PM
F3881014: Artboard M82_160406.png
Apr 16 2016, 2:30 AM
F3810524: links-alt.png
Apr 1 2016, 5:12 PM
F3810585: form-proposed.png
Apr 1 2016, 5:12 PM
F3810587: form-alternative.png
Apr 1 2016, 5:12 PM
F3810502: links-proposed.png
Apr 1 2016, 5:12 PM
F3810496: links-button-blue.png
Apr 1 2016, 5:12 PM
Tokens
"Doubloon" token, awarded by RandomDSdevel."100" token, awarded by Liuxinyu970226."Love" token, awarded by Pcoombe."Like" token, awarded by Prtksxna."Love" token, awarded by Volker_E."Love" token, awarded by Jdforrester-WMF.

Description

Artboard M82 Color Palette 2016-09-19 (WCAG compliant).png (1×1 px, 215 KB)

Improved color palette as of September 2016, compliant to WCAG 2.0 level AA


Find a palette that complies with the below listed criteria while staying true to our Wikimedia identity (trustworthy, academic, neutral, open, inviting).

WCAG 2.0 color contrast guidelines:
WCAG 2.0 level AA compliance (normal text size and 18pt+) – necessarily
WCAG 2.0 level AAA compliance (normal text size and 18pt+) – where possible
2022 update for people browsing by this task: It makes 0 sense to have some colors AAA compliant, the affected user groups still can't work with majority of interface. What we aim for instead is making our products work with specific software of those user needs, while supporting AA out of the box.

A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, the user with 20/80 visual acuity would require contrast of about 7:1 [to pass all four criteria including WCAG AAA at normal text size].

Tools used for contrast checking: Webaim, Snook.ca, Contrast checker

Tool used for color-deficiency simulation: Sim Daltonism (Mac OS, iOS); alternatively: Accessibility color wheel (Online tool, simulating protanopia, deuteranopia & tritanopia)
We're checking mostly on the most common color-deficiency— the Red–green color blindness (Protanopia, deuteranopia, protanomaly, and deuteranomaly).
This deficiency experience difficulty with discriminating red and green hues.


All chosen colors must be extensible and modular. This is so we can apply as little guideline as possible and let the usage be as endless as possible for all contributors.

Be mindful of the most used text colors—white and black.


Current situation after T110555:

MediaWiki theme buttons 2016-08-26.png (34×413 px, 6 KB)

//

Report from Contrast checker:

Screenshot 2015-08-21 16.15.34.png (450×736 px, 111 KB)

//

Tested on Sim Daltonism for the most common color deficiency:

  1. Protanopia

Screenshot 2015-08-21 16.30.58.png (154×1 px, 30 KB)

  1. Deuteranopia

Screenshot 2015-08-21 16.31.01.png (146×1 px, 29 KB)

  1. Protanomaly

Screenshot 2015-08-21 16.46.51.png (128×1 px, 29 KB)

  1. Deuteranomaly

Screenshot 2015-08-21 16.45.50.png (126×1 px, 28 KB)

Related Objects

StatusSubtypeAssignedTask
Resolved Spage
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
InvalidVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedNone
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
DuplicateVolker_E
ResolvedNone
ResolvedJdlrobson
ResolvedJdlrobson
Resolved Nirzar
ResolvedVolker_E

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

So, T110555: Consolidate progressive and constructive buttons happened and constructive buttons are no more! :D Does this change anything about this task (other than obviously removing the need to update one of the colors)?

The current patches are:

Change 264198 merged by Jforrester:
MediaWiki theme: Make colors' contrast compliant to WCAG 2.0 level AA

https://gerrit.wikimedia.org/r/264198

Why wasn't black included in the contrast tests? I'm not visually impaired and I can barely tell the difference between the dark blue and the black on a non-primary button.

To answer my own question, it seems like contrast between the colours was not considered at all - which is why we had the issue with almost no contrast between blue and green (before we solved that by getting rid of green).

I've reverted the patch from this week's OOUI release to let this discussion continue.

@Esanders The plan of getting rid of the "green" as button color dates back as long as the current task. I've asked for further information at T110565#2123979 on what the current way of selecting when to use which button in OOjs UI are currently? Would you provide more information over there?

Sure, have done. As recently as the patch @matmarex commented on on Jan 15 there was a design for a green colour.

The WCAG level AA compliant green wasn't meant to be used in buttons any more. That was not a "design", more application of the changes on the current technical implementation. It's a secondary color for highlighting of links as raised in T116549: Provide a color palette and design for buttons that are purely highlighted links, to distinguish them from actual UI buttons

The portal page seems to use the new blue (next to black text). In case it is useful as a reference:

wikipedia-portal.png (876×842 px, 204 KB)

Thanks Pau, I just noticed that. I think we should be coordinating any changes to the colour scheme so they are rolled out at the same time.

I've been looking to this with some more detail. Some thoughts:

The goal

I tried to capture what we need form the blue color. We need a blue color that:

  • Respects accessibility guidelines (color contrast in particular).
  • Can be used for different kinds of actions such as buttons and links.
  • Can be used as background for text (text in light color to keep contrast).
  • Communicates the Wikimedia brand and values (“academic”, reliable, aligned with the colors of logos, etc.)
  • Aligns with other colors of the palette (red and secondary link green)

Challenges

There are several (generic and specific) challenges:

  • Color is subjective and context affects its perception. In this context, how do we evaluate that “it works”?
  • The different uses of blue requires it to provide enough contrast with respect to several colors: a blue button with white text should be readable, but also a blue link should be distinguishable from a non-interactive black label.
  • Is not clear how much contrast we need between blue and black: too much and links can become jarring, to little and links cannot be recognised.
  • We aim for the maximum level of compliance with accessibility guidelines.

Comparing colors

The first step would be to confirm if there is a problem with the blue proposed in the ticket when it is presented alongside black. For that purpose I compiled two sets of examples. It would be great to hear about how well blue works in these context from the people involved in the selection of the proposed blue since they may have take other considerations into account that I'm not aware of. Can we distinguish active elements (blue) from passive elements (black) without effort?
Is it too jarring/distracting?

Example 1: text and links
I took a random Wikipedia article and changed the color of links to check how it fits with text.

Current blue used for links (#0645ad):

link-blue.png (723×800 px, 273 KB)

Current blue used for buttons (#347BFF):

links-button-blue.png (724×800 px, 268 KB)

Blue proposed in this ticket (#165C91):

links-proposed.png (724×800 px, 274 KB)

Alternative accessible blue (#0051B8):

links-alt.png (723×800 px, 273 KB)

Example 2: Buttons and text
I created a combination of widgets simulating a UI with different kinds of buttons.

Current blue used for links (#0645ad):

form-current-links.png (171×314 px, 13 KB)

Current blue used for buttons (#347BFF):

form-current-button.png (171×314 px, 13 KB)

Blue proposed in this ticket (#165C91):

form-proposed.png (171×314 px, 13 KB)

Alternative accessible blue (#0051B8):

form-alternative.png (171×314 px, 13 KB)

Thoughts?

I like the idea of using a colour that matches the blue used in our text links.

How did you choose the "Alternative accessible blue (#0051B8)" ?

Also, what tool/website did @violetto use to evaluate/screenshot the color-blindness simulations in T109915#1880133 ?

I believe an additional criteria (or decision point), is which of these we choose:

  • a single all-purpose color scheme that prioritizes maximizing accessibility for everyone, without needing any additional options. (The current proposal from Violetto et al)
  • a scheme that gives more weight to aesthetics, but we also offer optional accessibility overrides, such as discussed/wireframed in M17 etc. (See specifically the example of Battlefield's 3 color-blind options - (4 screenshots))

How did you choose the "Alternative accessible blue (#0051B8)" ?

It was an example using a color contrast tool in the somewhat limited range that AAA colors provide. It's just an attempt of making the blue more distinguishable from black while still working as a background for white text. It may not be the best option or break some other criteria but I thought it could be a good point of reference.

Also, what tool/website did @violetto use to evaluate/screenshot the color-blindness simulations in T109915#1880133 ?

Sim Daltonism was mentioned in the ticket description (and the one I used), but there may be others.

I believe an additional criteria (or decision point), is which of these we choose:

I think we should aim for reaching as many people as possible without further adjustments. Users may land in any page from their search engine, they may be logged-in or not (and switching preferences means they have to reach them navigating through the environment before it is adapted to suit them). Providing alternative experiences or compromising may be needed if serving a group of users means to break the experience for others, but I think that should be the last resort.

Sim Daltonism was mentioned in the ticket description (and the one I used), but there may be others.

As this is a Mac/iOS only tool, I've added the accessibility color wheel (online tool, simulating protanopia, deuteranopia & tritanopia) to the task description yesterday.

I believe an additional criteria (or decision point), is which of these we choose:

I think we should aim for reaching as many people as possible without further adjustments. Users may land in any page from their search engine, they may be logged-in or not (and switching preferences means they have to reach them navigating through the environment before it is adapted to suit them). Providing alternative experiences or compromising may be needed if serving a group of users means to break the experience for others, but I think that should be the last resort.

Second that, we should be inclusive by default where within sensible (time/budget/user satisfaction) reach.

Change 277889 had a related patch set uploaded (by Bartosz Dziewoński):
[Reapply] MediaWiki theme: Make colors' contrast compliant to WCAG 2.0 level AA

https://gerrit.wikimedia.org/r/277889

Another issue is that the hover and active states make the button darker, then even darker. Starting with a darker blue will lower the contrast between these states too.

Another place for reds, greens and grays and accessibility – .mw-plusminus* and .autocomment in shared.css of core: https://gerrit.wikimedia.org/r/#/c/283571/

Change 309483 had a related patch set uploaded (by VolkerE):
MediaWiki theme: Enhance button styles and align them to new color palette

https://gerrit.wikimedia.org/r/309483

Change 277889 merged by jenkins-bot:
MediaWiki theme: Make colors' contrast compliant to WCAG 2.0 level AA

https://gerrit.wikimedia.org/r/277889

Jdforrester-WMF edited projects, added User-notice; removed Patch-For-Review.

This'll go out in OOjs UI 0.17.9, and thus MediaWiki 1.28.0-wmf.20.

Change 309483 merged by jenkins-bot:
MediaWiki theme: Enhance button styles and align them to new color palette

https://gerrit.wikimedia.org/r/309483

Volker_E updated the task description. (Show Details)

Reopened as mediawiki.ui in core has to feature the agreed-on and WCAG compliant colors as well (currently preparing a patch set).

Change 264248 merged by jenkins-bot:
mediawiki.UI: Make colors' contrast compliant to WCAG 2.0 level AA

https://gerrit.wikimedia.org/r/264248

As it wasn't included in wmf.20, when will this be in production now?

As it wasn't included in wmf.20, when will this be in production now?

It was in wmf.20. https://gerrit.wikimedia.org/r/#/c/310374/

This comment was removed by Johan.
This comment was removed by Johan.
Volker_E updated the task description. (Show Details)