Views' text color does not have sufficient contrast

This needs to specify which color contrast ratio we are validating against. The gate doesn't seem to specify.

As a rule of thumb Drupal targets WCAG 2.0 AA. Updating gate page.

Edit: Someone else can feel free to update the appropriate documentation, I don't have time this morning and the task will get lost :)

@Everett Thanks, now people should be able to do a full review. I have adjusted all appropriate documentation.

Some other good tools to make this easier:

• Webaim's Contrast Checker
• Snook's sliders
• Niquelao's Mozilla extension

So this will be the first critical, to hit the core queue. I have not done a full review, but upon start, I did notice that the views main landing page does not have sufficient contrast and uses color as the only way to communicate meaning.

Foreground color: #999999
Background color: #f3f4ee
Contrast Ratio: 2.6:1

WCAG AA: Fail
WCAG AAA: Fail

#1802678: [META] Views: accessibility review is one critical to cover all of the sub issues. Otherwise thresholds will be completely destroyed :)

Setting back to critical as per #1805996-41: [META] Views in Drupal Core.

I reviewed the views UI Screens(Admin Listing Page, Views Add/Edit Page, Edit Popups) in Seven 8.0-dev (admin theme), using the tool Contrast-A

Views Admin Listing Page

Add/Edit page

Edit Popup Screen

Really surprised to see the dropbutton background is not valid. What is the minimum gray background on our current blue link foreground, we can have that validates?

The core gates say we only need to meet WCAG AA, so about four of those above are Pass, not Fail.

I'd like to help with testing if still needed, but I'm not sure what I have to do.

Looking at Priority levels of issues, can someone clarify whether this lack of contrast renders the system completely broken and not usable at all (critical) or merely makes it difficult to use (major/normal)?

For now, demoting to major until we get an answer to that question.

It has a relatively two simple reasons;

1) It is a hard gate requirement, we resolved (as far I know) all WCAG contrast compliance's in D7 so this would be regression.
2) It satisfies the critical requirement, that it has such an impact on legibility that people with certain deficiencies will not be able to read the text. We cannot show this, because as far I know deficiencies beyond just color are hard to simulate thus no tool does it accurately.

From the WCAG guide, http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast... :

"A contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision. The 4.5:1 ratio is used in this provision to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.

The rationale is based on a) adoption of the 3:1 contrast ratio for minimum acceptable contrast for normal observers, in the ANSI standard, and b) the empirical finding that in the population, visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5 [ARDITI-FAYE]. 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.

Hues are perceived differently by users with color vision deficiencies (both congenital and acquired) resulting in different colors and relative luminance contrasts than for normally sighted users. Because of this, effective contrast and readability are different for this population. However, color deficiencies are so diverse that prescribing effective general use color pairs (for contrast) based on quantitative data is not feasible. Requiring good luminance contrast accommodates this by requiring contrast that is independent of color perception. Fortunately, most of the luminance contribution is from the mid and long wave receptors which largely overlap in their spectral responses. The result is that effective luminance contrast can generally be computed without regard to specific color deficiency, except for the use of predominantly long wavelength colors against darker colors (generally appearing black) for those who have protanopia. (We provide an advisory technique on avoiding red on black for that reason). For more information see [ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI].

The contrast ratio of 4.5:1 was chosen for level AA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1.) 20/40 is commonly reported as typical visual acuity of elders at roughly age 80. [GITTINGS-FOZARD]

The contrast ratio of 7:1 was chosen for level AAA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/80 vision. People with more than this degree of vision loss usually use assistive technologies to access their content (and the assistive technologies usually have contrast enhancing, as well as magnification capability built into them). The 7:1 level therefore generally provides compensation for the loss in contrast sensitivity experienced by users with low vision who do not use assistive technology and provides contrast enhancement for color deficiency as well."

So it is not possible to use for a portion of our userbase. I don't really dare to change statuses anymore, so feel free to mark this whatever you guys want.

I don't really want to get into a discussion about priorities here either. Ultimately i want to see Views (and all of Drupal 8) meet WCAG 2.0 AA.

I think there are about 5 places that the CSS would need to change. This should be a relatively trivial to do given that @ramkumarr has done such a great job identifying where the interface fails due to Contrast-A.

Ultimately if we're building D8 for mobile, then AA is really got to be the minimum. More than ever folks are going to be administering Drupal from their mobile devices & heck, maybe from the beach on a nice day. Ensuring there is sufficient contrast helps everyone.

Either I or someone at the VDC sprint will work on getting us to WCAG AA.

Bojhan's summary of why this is critical looks reasonable to me.

Postponed on #1826574: Move Views theme-specific CSS to their respective themes, since some of Views color styling is overriding the themes', and once refactored may resolve this issue.

#1826574: Move Views theme-specific CSS to their respective themes is committed so back to active here

Great, how's this work for folks. Believe it addresses all of the WCAG 2.0AA points.

Edit: Some of the changes are with Dropbutton and are made in Bartik & Seven.

Thank you for working on that!
I guess someone should post a report again, so it's sure that the patch fixes it.

Can we see that in action? Before/after

That patch is not rolled against HEAD, it was blocked until #29 for a reason :) All of those files are gone now.

Grayed out styling of disabled views on /admin/structure/views. Views display tabs on the views /edit page are in progress.

Before

After

I would prefer if we shoot for AAA for color contrast. Not only does it help those with vision problems, but also mobile users who happen to be outside.

Hmmm I'm not a fan of the proposed solution...

I wanted to get a patch started so we could get this issue rolling. It really shouldn't be a hard fix. For the most part it's a matter of emulating what's already done in core.

Dropbutton has some bad colour contrast, so does Views. Core (prior to Views) may still have had some areas that weren't WCAG 2.0 AA. Can't recall off hand.

@dcmouyard tonnes of good reasons to shoot for AAA - let's see if we can make it happen. But let's make sure we get AA first.

@aspilicious - please give details or improved patches. The after patches don't look like what I saw locally, but then again, apparently "patch is not rolled against HEAD"... Gotta look into that.

I mean just visually based on the screenshot. I know we want to improve the contrast but if it's possible we should keep it "prety" at the same time. No clue how to improve it I think it's a metter of trial and error untill you find the "best" combination.

I think it would be better to seperate active and inactive views out into their own tables. Would gives the 'empty pattern' in the blank slate situation. The proposed solution puts visual attention to the disabled ones, it's visually very heavy. Splitting into two tables would allow us to *not* having to use color to indicate status.

@yoroy, it's funny you should mention that approach. We spent at least a half an hour debating if the UX maintainers would think that it was a good idea, but it was the same one we came up with :)

However, that should be it's own issue, and is completely unrelated to color contrast. So, I've opened a follow-up issue: #1830822: Split the Views UI listing into two tables for enabled and disabled

This issue should focus on meeting the color contrast standards of WCAG AA.

splitting is indeed another issue. It does help us here in removing the contrast bug without having to express state.

This should work better. With this patch Views color contrast will be better than Bartik's. I'll open a follow-up post about Bartik. This was using the Mozzilla Plugin ColorChecker which gives a nice summary.

Edit: The main issue I ran into with Bartik was with the header and depending on where it is in the background gradient it does or does not meet WCAG 2.0 AA. At the bottom of the font it doesn't, but it does around the middle. The validator went by the base color.

+++ b/core/modules/views/views_ui/css/views-admin.contextual.cssundefined
@@ -31,7 +31,7 @@ html.js #views-live-preview div.contextual {
+  border-radius: 0 4px 4px 4px;008BCB

This looks wrong :)

+++ b/core/modules/views/views_ui/css/views-admin.contextual.cssundefined
@@ -49,13 +49,13 @@ ul.contextual-links li span {
-  color: #666666 !important;
+  color: #666 !important;

+++ b/core/modules/views/views_ui/css/views-admin.theme.cssundefined
@@ -478,8 +478,8 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  background-color: #666666;
-  color: #ffffff;
+  background-color: #666;
+  color: #fff;

@@ -521,7 +521,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  background-color: #dddddd;
+  background-color: #ddd;

@@ -702,7 +702,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  color: #666666;
+  color: #666;

@@ -773,7 +773,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  border-color: #aaaaaa;
+  border-color: #aaa;

@@ -905,7 +905,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  border-color: #CCCCCC;
+  border-color: #CCC;

@@ -1014,7 +1014,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  border-color: #dddddd;
+  border-color: #ddd;
   border-spacing: 0;

@@ -1025,7 +1025,7 @@ ul#views-display-menu-tabs li.add ul.action-list li{
-  color: #666666;
+  color: #666;

This is unrelated to the issue and should be removed.

Found some invalid CSS in views-admin.contextual.css:

-  border-radius: 0 4px 4px 4px;
+  border-radius: 0 4px 4px 4px;008BCB

I'll continue checking the color contrast ratios.

By the way, my favorite color contrast tool is http://leaverou.github.com/contrast-ratio/

I'll change the border-radius issue for sure.

But isn't shortening (and for that matter making the upper/lower case formatting consistent) of the CSS a good thing. I didn't need to include it but it was bothering me and doesn't affect the design.

Can only help performance.

Can only help performance

Nope. Just a coding style, which is not part of this issue. That's called scope creep, or patch context switching

Some the color contrast changes go beyond AAA contrast. I'll work on a patch that has the least color contrast that still passes AAA.

This is unrelated to the issue and should be removed.

Personally, I think cleaning up CSS to match Drupal Coding standards should happen whenever we touch a style sheet.

#48, this issue is only about meeting WCAG AA.
Cleaning up any specific lines you touch is fine, but not any random part of the file.

Also, this issue is still assigned to @dead_arm, and I think she has a patch she was working on.

#48, this issue is only about meeting WCAG AA.
Cleaning up any specific lines you touch is fine, but not any random part of the file.

Okay, then is there an issue for cleaning up Views UI CSS?

Also, there are some color contrast issues due to the Seven theme that aren't Views specific. Should those be fixed in this issue if they're visible within View UI? Or is there a separate issue for making Seven have sufficient color contrast?

Okay, then is there an issue for cleaning up Views UI CSS?

No, you can open one for post-feature freeze if you'd like.

Should those be fixed in this issue if they're visible within View UI?

No, since that's a pre-existing problem, that shouldn't be grouped into this issue.

This patch fixes color contrast issues that are in Views only. It does not address other color contrast issues that are already in Seven or Bartik, even though they're visible on some Views UI pages.

I'll be posting screenshots later.

Cross-linking #1830822: Split the Views UI listing into two tables for enabled and disabled

Views Table

Seven Before & After

Bartik Before & After

Views Edit Page

Seven Before & After

Bartik Before & After

Views Dialog Popup

Seven Before & After

Bartik Before & After

We've now got lots of good screenshots of the patch. We just need someone to mark this RTBC? Need a usability review? Looks like we're almost there.

In looking at the CSS I did wonder about:

+tr.views-ui-list-disabled.even,
+tr.views-ui-list-disabled.odd {
+  background-color: #dadada;
+  border-bottom: 1px solid #bebfb9;
+}

Is adding the bottom border going to have a UI change?

We should not be removing the zebra striping or changing the background colors at all on the views listing page. Just removing the greyed out text color is enough.

Is adding the bottom border going to have a UI change?

No, it just helps visually separate the disabled views.

We should not be removing the zebra striping or changing the background colors at all on the views listing page. Just removing the greyed out text color is enough.

I think having a different background helps differentiate between enabled & disabled views.

I wouldn't be opposed to reverting back to zebra striping on disabled views in #1830822: Split the Views UI listing into two tables for enabled and disabled.

@dcmouyard This issue is about color contrast. That change is unrelated to color contrast. All it does is complicate that other issue.

Agreed with Tim. This is a critical, lets be strict about the scope and *only* fix the issue at hand.

Attached patch removes the greyed out background I added in #34, and the original greyed out text because with #1830822: Split the Views UI listing into two tables for enabled and disabled a separate table with black text provides enough contrast.

Screenshots are attached with contrast changes that use Seven's colors on the views edit display tabs and header. I removed the change to the views-admin.contextual.css because the context in preview feature is currently not usable and contrast will be handled if necessary at that time.

+1 for me. I disliked the grey background. I'm happy with this.

I gave this a visual review, seems like its far more consistent with Seven now. That's great! There are a few places, where we could tweak the other colors, but frankly that's much better to do in tiny follow ups and not accessibility related.

Lets get this critical out of the way and commit it.

The patch in #62 doesn't address color contrast issues in views-admin.contextual.css or Bartik. It also misses some issues in Seven, particularly link colors.

Several of the CSS changes don't match Drupal CSS coding standards.

Also, some of the color changes have nothing to do with color contrast, but they do make it more consistent with Seven.

This patch is based on #52. It removes the disabled views styling (color and gray background) and incorporates some of the design changes in patch #62.

Note to committers: The patch in #62 is RTBC.

@dcmouyard, please take a screenshot of how your changes to views-admin.contextual.css appear. Because they currently don't violate color contrast.

Take a look at this CSS:

ul.contextual-links li a {
  color: #666666 !important;
  margin: 0.25em 0;
  padding-left: 1em;
}

ul.contextual-links li a:hover {
  background-color: #badbec;
}

That gives us a color contrast ratio of only 3.9 whenever you hover over that link, which doesn't pass WCAG AA.

Using #c9edff for the link color makes it pass.

Re-rolled patch from #62 to follow Drupal coding standards for color hex values and removed extra lines added. Leaving RTBC as no other changes were made.

@dcmouyard you clearly did not test those changes, because it is physically impossible to do so: #1837982: Contextual links within the Views UI preview are broken

We have an RTBC and finished patch, we shouldn't be trying to fix color contrast for something that doesn't even show up on a screen.

Ok, I'm quite confused by the last few comments, but it looks like there's at least some agreement on #62/#70, so...

Committed and pushed to 8.x. Thanks!

I'm not sure about the comments from #67 and #71, but here is #1840896: Views UI CSS Cleanup, a followup to #51.

Updated issue summary.

@xjm for clarity the follow-ups are the color contrast issues in the Seven theme.

from issue #13:
https://drupal.org/node/1806022#comment-6628290

and issue number #17:
https://drupal.org/node/1806022#comment-6655620

Which came out in the patches above, but were removed here because they weren't directly tied to Views.

I think that's tied to this code, but wanted to clarify before opening the follow-ups.

diff --git a/core/themes/seven/style.css b/core/themes/seven/style.css
index 3b5776a..2e92632 100644
--- a/core/themes/seven/style.css
+++ b/core/themes/seven/style.css
@@ -7,7 +7,7 @@ body {
   font: normal 81.3%/1.538em "Lucida Grande", "Lucida Sans Unicode", sans-serif;
 }
 a {
-  color: #0074bd;
+  color: #00619d;
   text-decoration: none;
 }
 a:hover {

diff --git a/core/themes/seven/style.css b/core/themes/seven/style.css
index 65abcc7..345974c 100644
--- a/core/themes/seven/style.css
+++ b/core/themes/seven/style.css
@@ -1219,7 +1219,7 @@ fieldset.fieldset-no-legend {
 /* @group Attachment details */
 
 #edit-display-settings-title {
-  color: #008BCB;
+  color: #00496e;
 }
 
 /* @end */
@@ -1239,7 +1239,7 @@ fieldset.fieldset-no-legend {
 
 .views-displays .secondary a {
   background-color: #f1f1f1;
-  color: #008BCB;
+  color: #00496e;
 }
 
 .views-displays .secondary a:hover > .icon.add {
@@ -1254,7 +1254,7 @@ fieldset.fieldset-no-legend {
 
 .views-displays .secondary .open > a:hover {
   background-color: #f1f1f1;
-  color: #008BCB;
+  color: #00496e;
 }
 
 .views-displays .secondary .action-list  li:first-child {
@@ -1270,7 +1270,7 @@ fieldset.fieldset-no-legend {
 }
 
 .views-displays .secondary .action-list input.form-submit {
-  color: #008bcb;
+  color: #00496e;
 }
 
 /* @end */

Comprehensive list of follow-ups:

On the Views landing page 1, 2, 3, and 4 pass. 5 has a follow-up in the Seven theme here #740756: Ensuring Proper Color Contrast for Seven and Dropbutton has a follow up here #1858206: Dropbutton background with gradient does not meet WCAG AA standard.

Follow-up for Views contextual color contrast from comments #44, #66 - #69, #71 here #1837982: Contextual links within the Views UI preview are broken.

Follow-up for Views UI meeting CSS coding standards from comments #46, #50, and #51 was created in #74 and is here #1840896: Views UI CSS Cleanup

Follow-up from comments #13 and #17 that were not addressed in the final patch for this issue:

• Breadcrumbs in Seven are the link color: #0074bd on background-color: #fff which passes AA.
• The red asterisk doesn't pass and is filed here #1217044: Clean up the CSS for System module.
• The greyed out displayed views contrast is no longer an issue because of #1830822: Split the Views UI listing into two tables for enabled and disabled.
• The regular and and add display links' white button background on the top of the views edit page do not pass and have a follow up here: #1858238: The views add display link on the views edit page does not meet WCAG AA.