Views' text color does not have sufficient contrast

@Bojhan, see "More info about color and contrast," linked above, and right here: http://drupal.org/node/464500

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 :)

Some other good tools to make this easier:

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

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

At present I don't have a a test environment in 8, but if anyone has a development box where I can login I'd be happy to check against 8 as well (as well as help with some of the other accessibility issues in the cue). I couldn't find information on which admin theme will be used in 8. Has a definite been set yet? So if someone can bring me up to speed I'd be grateful. Just to kick things off here is a test of 7 with the admin theme Seven (as benchmark) as well as address the issues in #10:

Main landing page

From what I can tell with testing with the Niquelao's Mozilla extension recommended in #9 the main view in views passes on the active divs, but fails on the disabled divs.

My recommendation would be to keep the same color scheme as is Seven for Drupal 7 in Drupal 8, but instead of greying out the colors have a Enabled and Disabled section with the same colors. This could also tie in with making navigating accessible, as well as address the issue in #10 with only being able to navigate through color.

Split the views landing page in enabled and disabled keeping the same color scheme for both

Enabled Views

View 1
View 2

Disabled Views

View 3
View 4

Further test results for the main landing page

Passes, except for:

• The above mentioned
• The linked headings at the top of the table (View Name, Tag, etc)
• The breadcrumb links in Seven

Add new view

Passes, except for:

• The little red asterisk
• The breadcrumb links in Seven

Add view from template

Passes, except for:

• The breadcrumb links in Seven

Import

Passes, except for:

• The little red asterisk
• The breadcrumb links in Seven

View itself

Passes, except for:

• Non active views button at the top, and the add button
• The h2 heading with the view title below that (the one with the arrow on the left side)

Please note that I don't know if there can variations in data or output that need to be tested? Maybe it's good to have some common use cases, we can test against.

Views Settings Basic

Passes, except for:

• The breadcrumb links in Seven

Views Settings Advanced

Passes, except for:

• The breadcrumb links in Seven

Please note though:

In general there is a pattern of small:options failing, usually there is only one of these per tested page, but I can't see in the tool where those are. Does anyone have an idea where I should be looking for those?
Because it would save me some time tracking those down in Firebug.

The other question I have is why not use the the same color scheme of the admin theme in 8, and make sure this is WCAG compliant, and that all modules take over the css? Wouldn't that save a lot of work?

It's advisable to check these results, as I don't know how good the Niquelao's Mozilla extension is, it is a first round, and I may have accidentally overlooked something. It could be handy to save the views section pages as html pages, so that we can run these through different tools, as well as check them manually (this goes for heading structure, etc, as well.) If we could post those, than people don't need to git 8. It could help testing.

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

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

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

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.

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

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

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

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

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.

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.

Well, #30 needs to be rerolled against HEAD (some of the CSS has been moved into the respective themes) and then combined with #34. For what it's worth, I think #34 looks great if it has an acceptable ratio.

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

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.

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

I'll continue checking the color contrast ratios.

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

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

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

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.

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

Related: #1830822: Split the Views UI listing into two tables for enabled and disabled

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.

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.

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

This seems like a good strategy to me, since we are adding a semantic, more usable and accessible way of differentiating disabled views in the other issue. I'd be in favor of committing #62 and opening followups for any remaining issues that are not views-specific. (See #13 and #17 for the followups).

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.

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.

Take a look at this CSS:

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.

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

Let's please file those followup issues and link them here?

See #13 and #17 for a full list of the accessibility violations found during testing, many of which were not Views-related.

The followups still didn't get filed. Leaving open as an active task until they are. :)

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.

Automatically closed -- issue fixed for 2 weeks with no activity.