Seven inactive tabs do not meet WCAG AA 1.4.3 for contrast

Looks like changing line 44 in tabs.css in Seven's theme will fix this.

Change from
background-color: rgba(242, 242, 240, 0.7);
to
background-color: rgba(244, 244, 242, 0.7);

Now, let's find someone who wants their first core commit!

Thanks Mark. What's the new ratio? Screenshots will help as well.

Is there a reason for these colors having an alpha value, instead of just being RGB? That makes it awkward to test the contrast.
Do the colours still have sufficient contrast in the hover, focus, active styles?

As I see the color contrast ratio with background-color: rgba(244, 244, 242, 0.7) is only 4.21 (foreground color: #0074bd, background color: #edede9), but normal text requires a contrast ratio of 4:5:1.

So I changed the value to background-color: rgba(253, 253, 252, 0.7) for a contrast ratio of exactly 4:5:1 (foreground color: #0074bd, background color: #fdfdfc).

I tested it with chrome audit and aXe, which seems to be a little more accurate than the chrome accessibility audit.

Hi @andrew,

tabs.css in the Seven theme (line 44) uses rgba, so I just did the same.

I got the exact value that I suggested from html_CodeSniffer, it suggested that colour, but thinking about it now, if we also have only .7 opacity, then I guess we'd need a slightly darker colour.

Applying the colours suggested by @mlkdev, I get contrast ratio errors:

Here's the current seven in active tab:

Here's what it looks like with @mlkdev's suggestion:

I'm afraid either you posted the same screenshot twice or my suggestion wasn't applied in your test (it looks to dark on the screenshot). Tested your and my suggestion again with the HTML-Sniffer tool. Seems the HTML-Sniffer is ok with both color suggestions and different tools have fine differences in the results.

With the HTML-Sniffer I got with rgba(244, 244, 242, 0.7) a color contrast ratio of 4.5:1 and with the value rgba(253, 253, 252, 0.7) a color contrast ratio of 4.87:1.

Before: In order to use the WebAIM color contrast checker to take into account the .7 opacity, I took a screenshot and use the the eye dropper tool in Adobe Photoshop to get the background color.

Here are the results from the WebAIM:

Foreground: #0074BD
Background: #EDEDE9

4.23:1 => fail normal text

After: Using the RGBA from #12, I did the same and it passes!

Foreground: #0074BD
Background: #F5F5F2

4.54:1 => passes normal text

#15 was part of mentoring for DrupalCampNJ 2018 (please make sure @quidkid gets commit credit when this lands). Here are the screenshots (didn't want to get DREditor setup yet for embed helpers b/c the current problems with it).

Before:

After:

Assigning back to @andrewmacpherson for final review.

Hi All!

I was having issues getting the patch in #12 to apply, then I also found that manually changing the values still caused contrast to fail. Here is a new patch with a different background color value.

Now, this totally passes AA but still fails AAA. Are we wanting to comply with AAA here too?

Thanks!

Best,
jds

@id-jds - thanks for looking at this.

What was wrong with the colour in #12, and how does #17 improve it? The report in #15 says the new ratio from #12 was 4.54:1. What ratio did you find? 4.54:1 is close to the threshold, so maybe there are rounding errors between different tools.

We're not aiming to satisfy level AAA here. The Drupal core accessibility gate aims for WCAG 2.0 level AA

Aside: this would be a lot easier if it was just RGB. I'm not sure if there's a reason we have so many RGB-A values in Seven, but they're certainly more awkward to test.

@andrewmacpherson – of course! I am happy to contribute. I double checked and the color from #12 is passing with 4.74:1 from WAVE Chrome extension. Though I would be happy to reroll #12 or #17 with an AA-compliant RGB value (without the A). Maybe a first step in transition to RGB values in Seven where appropriate?

Thank you!

Tagging as a good mentored bug for the NWDUG sprint this weekend.

Assigning this ticket to myself as I'm going to have a look at it as part of the #Nwdug_may18 sprint

Here's a patch with a new background colour of rgba(254, 253, 250, 0.7). This gives a contrast ratio of 4.5:1, so it looks like a good value to use.

The change makes the background lighter, but I think it's still visually distinct from an active tab:

Chrome's dev tools has a colour contrast tool which seems to take RGBA background values into account, which makes testing this issue a lot easier.

@andrewmacpherson and I verified this approach by making sure that the contrast ratio reported by Chrome's dev tools matched the ratio we got by using a colour picker. We used a colour picker to comparing the opaque link colour to the blended background colour shown on my screen. The final colour of the tab is equivalent to #F5F4EF and this passes with a link colour of #0074bd: http://contrast-ratio.com/#%230074bd-on-%23F5F4EF

I also noticed an issue with the contrast of a tab in its focus or hover state, but I've raised a new issue for that: #2972451: Seven's focused/hovered tabs do not meet WCAG AA 1.4.3 for contrast

RTBC: I'm happy with this, we tested the colours together at the sprint. The new colour hits the required contrast ratio spot-on, and has minimal impact on the existing design.

Testing colour contrast is often a pain when transparent backgrounds are involved. The new Chrome colour tools DO seem to calculate the contrast based on the combined background colour of multiple elements with transparency. This is going to be easier in future :-)

@Phil Wolstenholme - thanks for filing the follow-up issue. It's good to fix the contrast for the non-interactive state first, in this issue. The interactive styles can be fixed in a follow-up, otherwise issues like this can drag on.

This does fix the color contrast between the text and the background, but this causes a new problem - after this change it is a lot more difficult to distinguish between active and inactive tabs. I'm not sure if there's an easy solution to fix this. Anyway pushing back to needs review for some further feedback from the accessibility maintainers.

The active vs. inactive tab distinction doesn't rely on colour. They are mainly distinguished by borders:

• There are borders between the tabs, and these are darker than the background colours of the tabs.
• The active tab doesn't have a bottom border, it opens out onto the main content.
• The inactive tabs do have bottom borders, which separate them from the main content. They look like they are behind the active tab.

Even in greyscale, the tabs are clearly separated, and the active one can be identified. This screenshot comes from an achromatopsia (colour blindness) simulation tool:

Back to RTBC, I don't think #27 is an issue.

I didn't see any difference in achromatopsia mode. This mainly affects the use case where you have the first tab selected because of the border is not quite so visible in that case.

Before:

After:

Feel free to move this back to RTBC if you still feel like this is not a problem.

I'm trying to understand issue #29 raised by @laurii to see if this can be moved forward. Looking at the screenshot, I don't clearly understand the problem, and wonder if maybe this is the reason this hasn't moved in 2 years. Can someone clarify this?

Here is a screenshot of @laurii's comparison in achromatopsia mode:

I find the difference to be small, and the active tab still easy to distinguish. Based on this I'm moving this issue back to RTBC.

re-rolled against 9.1 dev.

Re-setting issue to Needs Review, re-test passed.

Linking open issues from the CivicActions Accessibility - VPAT.

tagging

How about we set an underline on the text of the active tab, so that way it is distinguished by more than just colour?

I'd also suggest, after 3 years, we get _one_ of the patches from this committed so that Seven will be in a better state than it currently is, and we create a follow-up for the achromatopsia issue (which I guess is not introduced by this fix, but rather is there already and should not be stopping us from incrementally making Seven better).

I like it. We can enhance it later, but this sounds like a very workable solution @markconroy.

Updated patch #36 to include active tab have css underlined. See images Old tabs and New tabs. Created MR. Moving to review

Fixed Custom Commands Failed.

Updated patch to fix custom commands failure.

I don't get it if we are using the MR approach or patches in this issue...

I correct the custom erros in the patch of comment #50.

Hi marcusvsouza,

I applied your patcth i just want to know why you added text-decoration: underline; in li,

background after applied your patch.

Please revert i'm happy if i learn.

Thanks!

My mistake, follows the correct patch.

This is a contrast issue https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#qr-visual-audio-con...

Applied #54 working fine and applied successfully
Thanks for the patch
For ref sharing screenshots .....

As a reminder, the "assigned" field is for indicating that you're currently working on something, it's not for indicating to the maintainers that you contributed to the solution and/or posted a patch. Then, when you've finished your work it's customary to set the field back to "unassigned" so that others can then do some additional work as necessary. Thank you.

The Seven theme has been removed from Drupal 10 core. I confirmed that this issue only affects Seven and no other themes included with Drupal core, so I am moving this to the contributed Seven project.

Hi @marcusvsouza,

I can still reproduce the Contrast issue after applying patch #54 to the Seven contrib theme 1.0.0-alpha1 as a Default theme and with Drupal core version of 9.5.6.

Moving this to "Needs work" and please see the attached screenshot for reference.
Thanks.