Aria-practices: Color contrast testing procedure and its documentation for APG examples

Created on 28 Apr 2020  路  15Comments  路  Source: w3c/aria-practices

The APG group would like to have standard procedure to test color contrast, high contrast mode for each APG example. This will be part of APG example review documentation and useful resources to anyone who would like to assist the review ARIA APG example.

  1. How to test color contrast/high contrast mode for ARIA example(@charmarkk @a11ydoer @carmacleod )
  2. Variances by browser settings(@shirsha - IE/Chrome @carmacleod - Firefox)
QA for APG Examples documentation

All 15 comments

One thing I discovered is that if you use Firefox to test Windows High Contrast Mode, you need to turn on WHCM _before_ opening Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1633911

Also, there is a setting regarding link colour which works independently of WHC in Firefox.

I thought the "dark blue links against black" bug was fixed, but it's only fixed if you first change the link colour yourself in FF's own settings. I changed mine to yellow, which results at times in yellow text against white pages if I'm switching between WHC and not. Something to be aware of.

Edit: I wonder about the listing of IE here, instead of Edge. Or is the assumption that the Chrome tested is a canary which supports WHC?

That's a good point @StommePoes - just had that thought too. I don't know that we should be listing documentation for IE since we dropped IE support earlier in the year (see #1304). Thoughts?

@StommePoes

I thought the "dark blue links against black" bug was fixed, but it's only fixed if you first change the link colour yourself in FF's own settings.

I didn't touch the FF settings because I prefer to always test with defaults (otherwise the size of the test matrix just goes exponential 馃槃). If I close Firefox, turn on WHC Black, and then reopen Firefox, I am able to open any number of tabs that all look ok (i.e. yellow links on black background). So the "dark blue links against black" bug does indeed seem fixed, but _only_ if Firefox has a chance to fully initialize with WHC already on.

Thanks for the reminder to test WHC White. I tried it out (without touching the FF color settings) and, as long as I turn on WHC White before opening Firefox, I can open as many Wikipedia tabs as I like, and they all look good, with white background, black text, blue links, and purple visited links (i.e. the default colors for WHC White).

I wonder about the listing of IE here, instead of Edge. Or is the assumption that the Chrome tested is a canary which supports WHC?

APG did drop support for IE, but we were talking about using IE for WHC testing yesterday, given that we thought FF had WHC inconsistency bugs (which it does, but it can still be used for testing if you switch on WHC first and then open FF).

Thank-you for nudging me to test with CrEdge! I knew that pre-chromium Edge supported WHC, but I thought that CrEdge didn't support it yet, given that it's still in canary in Chrome, but I just tried WHC in the latest CrEdge (version 81) and it's already supported! There's a bit of wonkiness in the Wikipedia header, but other pages I tried look correct. Visited links are the same color as unvisited, but that's the same as IE.

It's very cool that WHCM will _finally_ be supported in Chrome soon. Looking forward to being able to test in whatever browser I happen to be in.

I also discovered this _very_ interesting "coming soon" tidbit in the MS Edge blog:

Tooling to simulate high-contrast on websites being debugged in DevTools, allowing developers on both Windows and Mac platforms to test high-contrast layouts 馃帀

I guess we should still be testing in pre-chromium Edge just a little while longer... at least until CrEdge shows up in Windows Update for everybody (any day now? I've had it since it was released in January, but for whatever reason, the other 2 Windows machines in our household still have the old Edge. I thought they said April. 馃).

@a11ydoer

There are two important differences between IE/Firefox and Edge in HCM:

  • Edge always places text with a background color so that text on graphics remains readable (https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/HighContrast/explainer.md#ensuring-readability). IE and Firefox do not do this
  • Edge displays background graphics in HCM, IE and Firefox do not.

It should also be noted that the CSS properties for querying the HCM (forced-colors, prefers-color-scheme, inverted-colors, prefers-contrast, forced-color-adjust, -ms-high-contrast, -ms-high-contrast-adjust) are currently supported very differently:

In my opinion, they should therefore not be used at present.

@carmacleod

Thank-you for nudging me to test with CrEdge! I knew that pre-chromium Edge supported WHC, but I thought that CrEdge didn't support it yet, given that it's still in canary in Chrome, but I just tried WHC in the latest CrEdge (version 81) and it's already supported! There's a bit of wonkiness in the Wikipedia header, but other pages I tried look correct. Visited links are the same color as unvisited, but that's the same as IE.

I use chromiedge and WHC currently and there are several bugs, although all due to devtools... however Chris Heilmann suggested I check the canary for Edge which I did because he said there have been many fixes... and all my devtools bugs had been fixed.

The <mark> bug has not been fixed: IE and even canary Edge keep mark text black even if you use a Black theme. Firefox backplates it all with the yellow mark background colour.

@JAWS-test yes, Edge uses a "backplate" for text. When Chrome gets standard WHC support, it'll do the same, and FF has showing background images (and thus with a backplate) somewhere on their list of bugs, I just don't know where that is on their schedule.

When I'm auditing for WHC, I'll use either IE or FF for testing the no-background-images case, because I feel that's enough browsers to check if important info is lost without those images. If FF, Chrome and Edge all support background images, that'll no longer be on my list.

@StommePoes @carmacleod @charmarkk @JAWS-test Thank you all for Window High Contrast testing info. I will summarize findings and add those to APG example review document.

@JAWS-test I appreciate your codepen examples! Your second code pen example demonstrates that ms-high-contrast property works under WHC.

By the way, can you kindly add more details to understand what you mentioned below? Thanks for your consideration.

.... are currently supported very differently:
In my opinion, they should therefore not be used at present.

At APG meeting, we also talked about "current color" in terms of color constrast testing.

@carmacleod By any chance, do you remember the context of the discussion?

@a11ydoer
The different CSS properties for HCM and Dark Mode are interpreted differently or not by the browsers, so in my opinion they should not be used. But this is only an unimportant hint for APG, because I don't know of any example where these CSS properties are used. However, this hint could be included in the documentation for creating APG examples.

@JAWS-test Thanks for your prompt response. As far as I know, APG Examples do not use ms-high-contrast property at all. We can make note about those but that may be more relevant to code review section. Let me think about it. Btw, my understanding is that Dark mode is one of HCM options, isn't it?

Btw, my understanding is that Dark mode is one of HCM options, isn't it?

HCM and Dark Mode are different things. But there is the CSS property prefers-color-scheme that query both:

if the UA determines, based on Lab lightness, that the Canvas color is clearly either dark (L < 33%) or light (L > 67%), then it must match the appropriate value of the prefers-color-scheme media query and express a corresponding user preference for color-scheme. This will allow pages that support light/dark color schemes to automatically adjust to more closely match the forced color scheme. https://www.w3.org/TR/css-color-adjust-1/#forced

If a white on black scheme is used in the HCM (white font on black background), a dark mode should be detected automatically, although it is not a dark mode.

HCM overwrites all colors. Dark Mode, on the other hand, is a user preference to which a website can react but does not have to. This means that in dark mode the page is only adapted if the author uses appropriate media queries.

@a11ydoer The currentColor discussion that I mentioned on the call begins at https://github.com/w3c/aria-practices/issues/1132#issuecomment-534886650 and continues for several comments after that.

@a11ydoer
I quickly added some notes about testing WHCM to the Accessibility Review section of the Pull Request Review Process wiki page.

This is a bare minimum for testing WHCM, but I figured it was better to get something written down than not to have any steps at all.

Here's what I added:

  • Test in Windows High Contrast Mode (WHCM):

    • Turn on WHCM in Windows Settings - Ease of Access - High Contrast.

    • Open the example in Edge and Firefox (note that Firefox must be started after WHCM is on).

    • Test in both High Contast Black and High Contrast White themes.

    • Make sure everything has suitable contrast and important icons do not disappear.

    • Trick: the quickest way to turn off WHCM on Windows 10 is to tell Cortana to "Turn off High Contrast Mode".

Please try the steps out with any example, and make sure you agree that the steps accurately describe what to do.
Thanks!

Was this page helpful?
0 / 5 - 0 ratings