Fixing A11y contrast issues on the main view

[CharpentierLucas]

Good afternoon,
In order to reach WCAG 2.1 AA compliancy, there are some changes needed to the XWiki color themes.
First of all, since those changes are quite small (variation on a few colors of the main theme), I think this wouldn’t be a bad idea to update the default color theme (Flamingo → Iceberg) with these changes instead of creating a new “special WCAG” theme.

---

I used a couple of firefox addons for accessibility to point out contrast issues on the Main View (http://localhost:8080/xwiki/bin/view/Main/)

First, a WAVE analysis (WAVE Accessibility Extension – Get this Extension for 🦊 Firefox (en-US))

ID	Element	Foreground Color	Background Color	Current contrast ( /1)	Contrast description	Proposed solution	Proposed value
1	Menuhorizontal > wikilink > a	#FFFFFF	#3E7CBC	4.36	White on light blue	Make the bg darker	BG #3E79BC
2	id=“hierarchy” class=“breadcrumb breadcrumb-expandable” > active space dropdown > a	#777777	#F8F8F8	4.21	Grey on very light grey	Make the fg darker	FG #727272
3	xdocLastModification	#777777	#FFFFFF	4.47	Light grey on white	Make the fg darker	FG #727272
4	Doc-tags , xdocTags	#777777	#FFFFFF	4.47	Light grey on white	Make the fg darker	FG #727272
5	Xwikitabbar > li active > a > itemCount	#777777	#FFFFFF	4.47	Light grey on white	Make the fg darker	FG #727272
6	Navigation panel → jstree-clicked	#3173B5	#EEEEEE	4.25	Blue on light grey	Make the fg darker	FG #2F6FAF
7	Footer xwikiplatformversion a	#FFFFFF	#3E7CBC	4.36	White on light blue	Make the bg darker	BG #3E79BC

This analysis first returned 28 contrast violations. In order to correct these issues I found out that a few changes in the color themes variables were enough:

• @navbar-default-bg : #3E7CBC → #3E79BC
• @link-color : #3173B5 → #2F6FAF
• Custom properties: @gray-light:#727272; (from #777777)
  Note : Changing this value is convenient because it’s used in multiple elements at various places in the interface. However, it might create some other contrast issues such as on the Create Page where it clashes as a foreground on a highlighted background.

After those fixes, a WAVE analysis reports 4 violations on the page. Three of those are about hidden elements and can be overlooked for now. The fourth one is about the [+] symbol in the tag node (ID = 4). This element uses a variable from the old color themes that did not get a field in the new color theme (can’t edit in a few clicks).

---

Second, a Firefox inspector check:

ID	Element	Foreground Color	Background Color	Current contrast ( /1)	Contrast description	Proposed solution	Proposed value
1	Breadcrumb carets	#ccc	#f8f8f8	1.51	Light grey on very light grey	Make the FG darker	#727272
2	Breadcrumb separator	#ccc	#f8f8f8	1.51	Light grey on very light grey	Make the FG darker	#727272
(3)	Youtube video title	NAN	NAN	NAN	NAN	NAN	NAN
4	Like-number in like-button	Gradient #6296cb,#3E7CBC 50%,#386fa9	#fff	3.11, 4.36, 5.23 (effective 3.8→ 4.81)	White on a gradient from dark blue to light blue	Make the BG light part darker
5	[+] in tags	#777	#fff	4.48	Light grey on white	Make the fg darker	FG#727272

This analysis returns a total of 6 violations.
In order to solve some of these, we apply changes:

• @breadcrumb-color: #727272
  Note: This would be the largest change, making breadcrumb ‘characters’ way more visible. This makes the breadcrumb more visible, which could be negative on user’s focus on the actual content of the page.
• @btn-primary-bg: #386da7
  Note: This change in lightness could be reduced a lot if the range of the gradient on the button was reduced. Right now the “dark” part of the gradient has enough contrast, but even the “middle” part of the gradient is not contrasted enough, so a change of this center value is needed anyways.

After this, only two violations are reported: the [+] for tags, and the video title.

---

At last, I performed two analysis with Axe DevTools (axe DevTools® - Web Accessibility Testing – Get this Extension for 🦊 Firefox (en-US)) and IBM Accessibility Assessment (IBM Equal Access Accessibility Checker – Get this Extension for 🦊 Firefox (en-US)).
No additional violation was found out.

---

By changing a few colorTheme variables, we can reduce drastically WCAG contrast violations on the main theme.

Initial color theme

Updated color theme

Thanks for reading this proposal! I’m looking forward to your feedback, especially on the “gray-light” and “breadcrumb-color” changes.

[vmassol]

Sounds good to me. Visually I don’t see much change from the before/after images so that’s a good point and I think we could make those changes safely and it won’t affect too mch our users (the non-visually impaired users that is, for the visually-impaired ones, it’ll definitely help I’m sure ;)).

So +1 to make these changes to the default color theme (i.e. Iceberg).

[RohitChauhan98]

Hey! Please assign it to me…

[CharpentierLucas]

Hello @RohitChauhan98 and thank you for your interest in this topic
Unfortunately I started working on a solution for it last Friday.
https://jira.xwiki.org/browse/XWIKI-20680

Those are some unassigned issues of the XWiki platform project that you could tackle instead (after properly assigning them to your JIRA account) :
https://jira.xwiki.org/browse/
and set the filters to:

• Project: XWiki Platform
• Status: Open
• Assignee: Unassigned

Some various guidelines about how to contribute code:

Contributing - XWiki

[vmassol]

@CharpentierLucas

Those are some unassigned issues of the XWiki platform project that you could tackle instead (after properly assigning them to your JIRA account) :
Loading...

Seems like a bad URL. You need to click on “share”.

[CharpentierLucas]

@CharpentierLucas

After those fixes, a WAVE analysis reports 4 violations on the page. Three of those are about hidden elements and can be overlooked for now. The fourth one is about the [+] symbol in the tag node (ID = 4). This element uses a variable from the old color themes that did not get a field in the new color theme (can’t edit in a few clicks).

With a hard refresh the [+] from the tags dropdown is properly changed and does not return a contrast violation anymore.

---

When creating a page (http://localhost:8080/xwiki/bin/create/Main/WebHome), the xHint becomes too light (because set up as a text-smaller-muted→text-muted→ color:@light-gray which was made a bit lighter) when the type of its parent is “selected” .xwiki-select-option-selected so the background becomes a bit darker.

This can be solved in two ways:
• by making the text-muted get a darker shade of gray, namely @gray instead of @light-gray. The advantage is that there will probably be less accessibility issues with all kinds of elements using this text-muted formatting. However making it darker also makes it less muted and reduces the effectiveness of this formatting. In our example, the non muted text color is in dark grey #333, and we go from #777 to #555 for the muted text
• By making the .xform .xHint follow only .text-smaller (no .text-muted anymore) and color: @gray. While this solves our issue, this will have less consequences on the other parts of the interface.
So far, from my observations, the first solution doesn’t trigger unexpected contrast issues elsewhere.

---

@CharpentierLucas

@btn-primary-bg: #386da7
Note: This change in lightness could be reduced a lot if the range of the gradient on the button was reduced. Right now the “dark” part of the gradient has enough contrast, but even the “middle” part of the gradient is not contrasted enough, so a change of this center value is needed anyways.

On http://localhost:8080/xwiki/bin/view/Help/Applications/ , this issue of button contrast was found again, but this time with the “success” variation of the button.

The white text doesn’t have enough contrast on the light green gradient.
There is a need to make even the darker color of this gradient darker (on the violation, we can see that both the sides of the gradient fail the need for contrast).
However, on the contrary to the regular button where a -0.05 shift in lightness (using HSL) was needed, this one needs a -0.20 shift in lightness. Instead of being barely noticeable, this shift in color becomes quite noticeable.
Removing the gradient on this button and making it flat would still need a lightness shift to fulfill the WCAG 2AA contrast criterion of -0.16.
This is the result for the minimal change needed ( -0.20 ):

---

When viewing a livetable e.g. http://localhost:8080/xwiki/bin/view/Help/Applications/Movies/
The cross to delete the entry does not have sufficient contrast.

This can be changed from within the livetable presentation, or with the @brand-danger variable. When hovered, the background of the entry becomes darker. The foreground color of tbody.xwiki-livetable-display-body td a.actiondelete .action-icon is set by the variable $theme.notificationErrorColor mapped to the current variable @brand-danger.
There are two solutions, the first one has a lighter impact but does not ensure the contrast validity on :hover :

• @brand-danger #d9534f → #d33935 (-0.06 lightness)
• @brand-danger #d9534f → #ca302c (-0.10 lightness)

Here is an updated interface with the second solution:

---

New changes proposed:

• @text-muted: @light-gray → @gray;
• @btn-succes-bg: @brand-success (#56b881) → #31754f
• @brand-danger → #ca302c

Note: Those changes are not about the main view. I suppose they are still relevant enough to be part of this discussion / issue.

[CharpentierLucas]

The same contrast issue can happen with warning buttons. These buttons are yellow (see below).
Their saturation is very high so in order to increase contrast, we can either change a lot the lightness of the color (1) , or cut down the contrast and decrease less the lightness level (2). However, both of these solution end up in a completely brown color. I don’t think losing the semantics behind the yellow color of the button is good, so I propose we let go off the white foreground color to make it black/dark instead (3).
This solution is however debatable because all the other kinds of buttons at this point have white text colors. Changing all the button foregrounds to a dark color would probably be the cleanest way to ensure enough contrast on all button variations, but would lead to more visible changes on the most frequent buttons. E.g. for the regular “blue” button, changing text from white to black would be way more noticeable than the .05 lightness shift proposed above.

Contrast valid variations of a warning button
found by an administrator when viewing a regular user’s profile:
0. (Reference, contrast too low)

1. Lightness decreased
   
2. Lightness and saturation decreased
   
3. Foreground color swapped
   

What do you think of this?

[mleduc]

+1 for option 3 (based only on my own tastes)

[MichaelHamann]

I’m also +1 for option 3, though I’m wondering if we could make the background a bit lighter to further increase the contrast.

[CharpentierLucas]

4. Foreground color swapped and lighter background (#ffd483)
   

I’m not so sure about making the background lighter. If so, it needs to be a small change because there’s two possible drawbacks:

• Contrast with background (white/light grey in example, and most cases) will be reduced.
• Saturation won’t do as much even when cranked up (when made lighter, the color will get closer to white).

4 is a combination I thought was correct. Here, I increased saturation to maximum, with the same hue and a lightness increased from 0.62 to 0.76. The contrast between button background (middle of the gradient) and text is 15.0 while button background to page background (white) is only 1.4.
This wouldn’t be a WCAG violation, but even with the “dark” variation which is the default, we still have a contrast of 10.8 with the text, which is way higher than the 4.5 needed for the level we’re aiming for.

[mleduc]

@CharpentierLucas

4. Foreground color swapped and lighter background (#ffd483)
   
   

Starting to look a lot like Amazon theme But +1 for that one too.