Note 4 in definition "contrast ratio" still relevant (1.4.3, 1.4.6, 1.4.11)?

[JAWS-test]

https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#key-terms

I suggest to discuss and check whether note 4 under "Key terms: contrast ratio" is still relevant for 1.4.3, 1.4.6, 1.4.11 and to possibly abolish this note.

Background color is the specified color of content over which the text is to be rendered in normal usage. It is a failure if no background color is specified when the text color is specified, because the user's default background color is unknown and cannot be evaluated for sufficient contrast. For the same reason, it is a failure if no text color is specified when a background color is specified.

Reasons:

• I don't know of any page that meets 1.4.8 (first point: "Foreground and background colors can be selected by the user") in such a way that no colors are defined for text (https://www.w3.org/WAI/WCAG21/Techniques/general/G148), so the technique (which leads to the problem at note 4) is unlikely to be used by visually impaired people.
• In the browsers used by most people today, the colors cannot be set at all (in Chrome, for example). https://www.w3.org/WAI/WCAG21/Techniques/general/G156 mentions IE 7, but who has it? (It still works with IE and Firefox)
• I suppose most visually impaired people use their own user styles or high contrast mode. With both methods the problem of Note 4 does not occur.
• For many people, the note is hard to understand, especially in combination with note 3 immediately before it: "If no background color is specified, then white is assumed."
• I have conducted a survey of accessibility testers in my country and found that almost no one knew about this note 4 and no one tests whether the note is met. It took me many years to find this note myself and to include it in my tests. There are some, but not many pages that violate note 4.

If note 4 should still be relevant, I suggest in WCAG 3.0 to include this directly in the SCs and not to hide it in the Understanding.

[mraccess77]

Hi @JAWS-test we do have F24: Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors without specifying background colors or vice versa.

[awkawk]

@JAWS-test we won't change this for 2.2 but have marked this with the "WCAG.next" label so we can have this on the radar for the future/silver.

[JAWS-test]

@mraccess77

we do have F24

I know F24 very well and always use it to explain what note 4 actually means.
But: I believe that note 4 is no longer up to date.

• on mobile devices it doesn't work at all in my opinion
• on desktop devices not in Chrome, which is used the most.

That's why I wanted to start a discussion if note 4 and all related failures and techniques are still needed.
I like the idea that the text color can be changed without changing all colors (as it would be in HCM). But G148 seems unsuitable for that. Better would be G175 or any new technology.

@awkawk:

we won't change this for 2.2

That was clear to me, so it was a suggestion for WCAG 3.0, as I wrote.

[JAWS-test]

I don't want to leave unmentioned that with a bookmarklet G148 works in any browser - only I hardly believe that except for testing purposes someone uses it.

[Myndex]

I suggest to discuss and check whether note 4 under "Key terms: contrast ratio" is still relevant for 1.4.3, 1.4.6, 1.4.11 and to possibly abolish this note.

Yes it is still very relevant, and in fact is in the TITLE of technique G148:

> Not specifying background color, not specifying text color, and not using technology features that change those defaults

Reasons:

• I don't know of any page that meets 1.4.8 (first point: "Foreground and background colors can be selected by the user") in such a way that no colors are defined for text, so the technique (which leads to the problem at note 4) is unlikely to be used by visually impaired people.

Not true. You need to read the TECHNIQUES that go along with the SC, and G156 addresses this directly.

• In the browsers used by most people today, the colors cannot be set at all (in Chrome, for example). mentions IE 7, but who has it? (It still works with IE and Firefox)

This is not true.

Colors can be set in all the major desktop browsers, including but not limited to Edge (replaced IE), Safari, Firefox, and yes even Opera and Chrome.

Edge and Safari can directly load custom user style sheets in the UI, Firefox allows access to the defaults as described here.. Chrome (and Firefox) are theme-able, Chrome and Opera have extensions that allow custom sheets, custom colors, inverting polarity, contrast and even daltonization (recolor for CVD).

But "user style sheets" are mostly worthless, as a poor "one size fits all" approach that usually ends up breaking sites, and NOT really addressing functional needs while throwing away all the design of the author.

What Chrome, iOS, etc etc are doing instead is ADDRESSING FUNCTIONAL NEEDS, by allowing users to make relative adjustments of font size, zoom level, contrast, polarity, etc. which is ultimately more useful than a style sheet that throws out the entire page design.

RELATIVE adjustments are useful. Overriding the author in total is not nearly as useful. User style sheets also have potential security issues.

The major modern desktop browsers, and the modern mobile devices all have accessibility controls which directly assist functional needs for these purposes. By modern I mean the last 8-10 years. BUT, these controls can be made worthless if authors create non conforming content.

• I suppose most visually impaired people use their own user styles or high contrast mode. With both methods the problem of Note 4 does not occur.

It is not relevant if some use cases prevent the problem, the fact is that not all use cases prevent the problem. But user styles and high contrast mode are by far not the only accessibility controls ona modern device. Switching to some modes can definitely make a problem worse when a FONT color is defined but the background is not defined.

That is the entire point of the technique - if you define BG or Text, you MUST define the other, because you will not know definitively what the user agent is using.

• For many people, the note is hard to understand, especially in combination with note 3 immediately before it: "If no background color is specified, then white is assumed."

The note is very clear in english. Citing also my response to you in that other thread, perhaps this underlines the importance of translations. There are some translations here:

https://www.w3.org/WAI/standards-guidelines/wcag/translations/

• I have conducted a survey of accessibility testers in my country and found that almost no one knew about this note 4 and no one tests whether the note is met. It took me many years to find this note myself and to include it in my tests. There are some, but not many pages that violate note 4.

That's weird because it is quite clear in Techniques G148. As for pages not violating it: that would be an expected result. Defining a BG color but not font or vice-versa is a pretty big design mistake. The fact that few sites make this mistake does not therefore mean it is not needed in the standard!

If note 4 should still be relevant, I suggest in WCAG 3.0 to include this directly in the SCs and not to hide it in the Understanding.

It is not hidden in understanding, it is listed in techniques G148.

[Myndex]

@JAWS-test we won't change this for 2.2 but have marked this with the "WCAG.next" label so we can have this on the radar for the future/silver.

Hi Andrew @awkawk — for Silver this probably fits as part of the "customization paradigm," though I don't see a real change as it refers to a mandate to define adjacent colors, or if one is undefined, all should be undefined so all use only the user agent.

I can't imagine many cases where you'd want to leave some, but not all, colors undefined. Perhaps the understanding doc should indicate that user agents may vary in default colors, so all color should be defined as a best practice.

I see how there could be issues testing, for instance Medium.com seems to set BG with javascript, so it's not in the CSS, and Chrome does not report the BG color as set by Medium's JS from what I can tell (weird?) If an automated tester is just looking at CSS and not executing the JS, it would see that as a fail I'd think.

[JAWS-test]

@Myndex Hi Andrew, I'm afraid I don't understand your remarks at all. I have assumed that the following order applies when determining the colors in the browser (https://www.w3.org/TR/css3-cascade/#cascading-origins):

1. high contrast mode of the operating system (not supported by Chrome) or color filters of plugins (like in Chrome) or color filters of the screen magnifiers like Zoomtext
2. user styles (defined by the user of the browser)
3. CSS of the web authors
4. colour setting in the browser or operating system.

This order is valid if no !important is used.

For this reason, Note 4 of the definition of "contrast ratio" is not relevant for points 1-3 (in the list above). Note 4 is only relevant for the color settings in the browser (point 4) because they have the lowest priority. If only the foreground color is defined in the author's CSS (point 3) and the background color is defined in the browser (point 4): this can lead to unrecognizable content.

In Chrome, I don't know any way (except for points 1 and 2, which overwrite the authors' CSS and are therefore not problematic) to change the colors that were not defined in CSS. I only know this possibility in IE and Firefox and suspect that no user uses this possibility because there are no pages that do not define colors in CSS.

How can I change the colors in Chrome without Contrast plugin and without user styles? As far as I know, this is not possible: https://bugs.chromium.org/p/chromium/issues/detail?id=347016. For IE it is described here: https://support.microsoft.com/en-us/help/17456/windows-internet-explorer-ease-of-access-options?ocid=IE10_ignore_colors:

To choose website colors
1.Open Internet Explorer, select the Tools button  and select Internet options.
2.Select the General tab, and then, under Appearance, select Colors.
3.Clear the Use Windows colors check box.
4.For each color that you want to change, select the color box, select a new color, and then select OK.
5.Select OK, and then select OK again.

[Myndex]

@Myndex Hi Andrew, I'm afraid I don't understand your remarks at all.

I'm not sure how else to explain this to you. What translator software are you using? Because something is getting lost in the mix.

If the AUTHOR sets a color for a FONT, but does not set the color for the BACKGROUND, then the user agent background displays. Also the CSS cascade only applies to the items styled by CSS (including the user agent defaults). OS settings and color management settings are distinctly separate from CSS and the user agent, though I suppose windoes may have some differences — I do not support windows, so can't say.

If only the foreground color is defined in the author's CSS (point 3) and the background color is defined in the browser (point 4): this can lead to unrecognizable content.

Yes, that is what I said.

In Chrome, I don't know any way (except for points 1 and 2, which overwrite the authors' CSS and are therefore not problematic) to change the colors that were not defined in CSS.

Chrome uses "themes" and you can create all sorts of custom color sheets and link them to specific sites. And Chrome has about half a dozen plug ins such as DARK MODE that work pretty well.

How can I change the colors in Chrome without Contrast plugin and without user styles? As far as I know, this is not possible:

I told you at least twice now. I am doing it on Chrome right this second as I type this.

I don't know how much easier Chrome could make it - override site CSS sheets and keep the changes persistent so your changes remain when you reload.

For IE it is described here: https://support.microsoft.com/en-us/help/17456/windows-internet-explorer-ease-of-access-options?ocid=IE10_ignore_colors:

I really don't care about IE (last released in 2013) it was replaced by EDGE years ago... I know MS just replaced edge with their own Chrome (weird), but IE is a worthless dinosaur unless you have some clients on XP or something I guess.. Safari, Firefox, Opera all have custom options, AS DOES CHROME. The two Chrome extensions I like are Dark Mode and Color Enhancer. But Chrome works with themes and works with persistent local overrides as I have stated.

[JAWS-test]

@Myndex

As far as I've checked, none of the possibilities mentioned by you causes the following file to become invisible in Chrome:

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title>Note 4</title>
	</head>
	<body>
		<p style="color:black;background-color:white">both</p>
		<p style="background-color:white">only background</p>
		<p style="color:black">only foreground</p>
		<p>nothing</p>
	</body>
</html>

Note 4 is about paragraphs 2 and 3 becoming invisible when I adjust the colors in the browser. I can do this with IE 11 and Firefox, but not with Chrome.

• The Chromes themes don't influence the display of the web pages at all (only the display of Chrome)
• user styles overwrite the CSS, so the display is also correct
• High Contrast plugin changes all colors correctly.

I'm interested in a screenshot of my file in Chrome where paragraphs 2 and 3 are not visible and a description of how this was achieved. Of course under the condition that the user styles define foreground and background color (if you use user styles).

[mraccess77]

Regarding the background/color discussion -- there are settings in Firefox or IE to allow for overriding of page specified colors. When just that setting is on and not all colors are replaced then #2 and #3 are issues (and perhaps content that relies on currentColor). When that feature is not enabled or in browsers that don't support that feature that would not be an issue. So i'd imagine it's only an issue for certain browsers.

[JAWS-test]

@mraccess77

As I wrote in my first comment:

It still works with IE and Firefox

But not in Chrome and Edge.

The settings for IE 11 I described in #876 (comment).
For Firefox it is just in the settings > Color.

The Note 4 is relevant for IE 11 and Firefox - I am aware of. But my intiale question was a different one: Are there any users who use these settings of IE 11 and Firefox because these settings are mostly ineffective because the colors are defined in CSS.

[Myndex]

As far as I've checked, none of the possibilities mentioned by you causes the following file to become invisible in Chrome:

Then you haven't checked.

It seems I am talking about apple trees, and you're having a conversation about tomato vines — there's a disconnect in understanding somewhere.

Of course you won't make a fail when you just set the colors to standard user agent defaults that you are also already using in your browser. Nevertheless it is TRIVIAL to break, and DIRECTLY points to the need (and reason for) for the standard. Your assertion that it is not useful or needed is meritless.

Here are examples in Chrome:

---

Here with the text selected/highlighted so you can see the invisible parts:

---

---

AND

Are there any users who use these settings of IE 11 and Firefox because these settings are mostly ineffective because the colors are defined in CSS.

Incorrect. And you are ignoring the second most used browser, Safari. Nevertheless, while still in Chrome, here is a user override of ALL colors, without changing the last example page itself in anyway, only adjusting the local user overrides.

I'm interested in a screenshot of my file in Chrome where paragraphs 2 and 3 are not visible

The examples are above.

and a description of how this was achieved. Of course under the condition that the user styles define foreground and background color

No. This is now the third time I have explained this to you, and this time with examples all done in Chrome. If you still don't get it, there's a nifty site I heard of called Google.com and if you go there you can do a search and find all sorts of useful answers to questions like this. It's easy and free!

Seriously, there are a million tutorials on this, and I am obviously incapable of communicating with you.

Best of luck to you.

[JAWS-test]

If Note 4 should continue to exist, I suggest adding the following:

• Note for which elements this applies (only links and text, or also buttons which have a standard foreground and background color and are therefore not affected by the color adjustment in the browser - buttons are only affected if the standard colors are removed, e.g. with color:inherit or background-color:transparent)
• Note that a violation can also occur if the foreground and background colors are not defined and the text is above a graphic or a border (i.e. background color should not only refer to the CSS property background-color, but to the actual background of the text)
• Note that for 1.4.11 this also applies to graphics with transparent background.

[alastc]

• I don't know of any page that meets 1.4.8 (first point: "Foreground and background colors can be selected by the user") in such a way that no colors are defined for text (https://www.w3.org/WAI/WCAG21/Techniques/general/G148), so the technique (which leads to the problem at note 4) is unlikely to be used by visually impaired people.

I don't understand why this is a problem. The note says that if the author only specifies one of foreground/background then it's a problem. 1.4.8. asks the author to provide a mechanism for the user to select foreground/background colors, of which G148 is one mechanism.

• In the browsers used by most people today, the colors cannot be set at all (in Chrome, for example). https://www.w3.org/WAI/WCAG21/Techniques/general/G156 mentions IE 7, but who has it? (It still works with IE and Firefox)

Not the case, Chrome has a pluggin which (last time I tried) is auto-suggested to you if it detects HCM.

• I suppose most visually impaired people use their own user styles or high contrast mode. With both methods the problem of Note 4 does not occur.

Or a pluggin like Stylish (which has millions of users, some with LV needs) which over-rides the CSS on a more granular basis. However, that doesn't impact Note 4.

• For many people, the note is hard to understand, especially in combination with note 3 immediately before it: "If no background color is specified, then white is assumed."

There is a graduation - if you don't specify one of the colors (whilst specifying the other), that's a fail. However, if you don't specify the background, here is a basis of measuring the assumed contrast, so that if you do set the background color (to white) then you know whether the text would have enough contrast in that scenario.

I see what you mean about those being confusing taken together, but they are relevant to slightly different scenarios.

• I have conducted a survey of accessibility testers in my country and found that almost no one knew about this note 4 and no one tests whether the note is met. It took me many years to find this note myself and to include it in my tests. There are some, but not many pages that violate note 4.

I'd be interested to know how many people (and how many different organizations) that was.
In any case, there is a failure technique for this, I'm not sure how it could be more explicit.

[mraccess77]

@alastc The chrome extension does not allow users to choose colors or replace the background or foreground with a specific value. The extension is not effective for real uses.

[Myndex]

@alastc The chrome extension does not allow users to choose colors or replace the background or foreground with a specific value. The extension is not effective for real uses.

Hi @mraccess77 Hi Jonathan,

There is a free Chrome plug-in that is everything you want and what whole lot more. It's called Dark Reader.

I came across it recently when I was researching available modification technologies. Here are a few screenshots.

DARK READER

The webpage on the left in it's normal and unaltered mode:

DYNAMIC MODE

It has a dynamic mode which allows you to invert the text content without inverting images. Note als. They've inverted contrast but they kept the colors the relative colors of the web design and the images the same. One of the things I hate the most about a lot of the inverted modes in OSs and other extensions is that they also invert the hue which is getting even farther away from the authors original intent.

RELATIVE CONTROL

Along with inverting or if you want instead of converting you have very fine control over the overall brightness and contrast and it makes changes relative to the content authors original intent as opposed to overwriting them.

GLARE REDUCTION

One of the interesting modes, is sepia mode which reduces blue, which is huge for people who have a problem with glare and chromatic aberration.

SPATIAL FREQUENCY

Another much-needed incremental feature, is the ability to change the stroke width a font. Much of my recent research shows that it is stroke width more than anything else that affects perception of contrast.

As set in site:

Increased in the app:

PER SITE STYLE SHEETS

And what I'm more incredible features is not only can you edit stylesheets independently in per site, have a library of user shared CSS sheets for different sites that'll allow more customization using dynamic mode.

I have no connection to this plug in whatsoever, but it is very much addressing the kinds of user relative changes but I've been talking about in some other threads.

Andy

[JAWS-test]

@alastc

I don't understand why this is a problem. The note says that if the author only specifies one of foreground/background then it's a problem. 1.4.8. asks the author to provide a mechanism for the user to select foreground/background colors, of which G148 is one mechanism.

That's not a problem. I only wanted to ask if Note 4 is obsolete, because Note 4 is only relevant under the following conditions:

• The colors can be set in the browser in a way that this setting has a lower priority within the CSS cascade than all other color settings (such as Autor Styles, User Styles, High Contrast Mode etc.): This is not possible in Chrome and Edge, but in Firefox and IE 11. To my knowledge mobile browsers cannot do this either. Whether it works in Safari, I don't know
• Visually impaired users adjust their colors in IE 11 or Firefox because there are pages that are not define foreground and background colors. I don't think such pages exist, so no user adapts her or his colors in the browser (but via user styles, plugins, high contrast mode, etc.) and therefore Note 4 is not relevant, because all display errors caused by the other color adjustments are not errors prevented by Note 4 and F24

I'm not sure how it could be more explicit.

It would be clearer if a note were made directly in the "Intent" chapter. This explains, for example, that the contrast requirements also apply to hover and focus states.

[JAWS-test]

By the way, note 3 only makes sense if it is supplemented as follows: " If no foreground color is specified, then black is assumed"

Because white and black are the standard colors of the operating system for background and foreground. If I only specify the one standard color in Note 3, what should be measured remains open if neither foreground nor background color are defined.

---

Understanding 1.4.3:
"Although this Success Criterion only applies to text, similar issues occur for content presented in charts, graphs, diagrams, and other non-text-based information. Content presented in this manner should also have good contrast to ensure that more users can access the information."

Here a reference to 1.4.11 would be good

[jake-abma]

Hi Andrew / @Myndex , just FYI sadly Dark Reader doesn't work well with web components. Our applications are not or badly changed / adjusted.

[alastc]

Interesting @jake-abma, I wonder if it's just a new-ness thing (needs work in the extension), or a fundamental way that CSS is applied to web components? Do other methods of applying user-styles work on web components?

[jake-abma]

@alastc It all depends on the author, the whole thing with web components is that you have global CSS and local CSS where you can isolate styles, use Shadow DOM for style encapsulation.

[Myndex]

Hi Andrew / @Myndex , just FYI sadly Dark Reader doesn't work well with web components. Our applications are not or badly changed / adjusted.

Hi @jake-abma do you have a URL of an example?

[JAWS-test]

@alastc Can the notes in the glossary be changed or do they belong to the unchangeable part of the WCAG 2.x?

[mraccess77]

HI @Myndex I tried the extension but it doesn't really give me the granularity for colors that I want. It makes contrast better but changes the color combinations to ones that I don't prefer in some areas but ones that are pleasant in others. These filter approaches tend to be like that.

[Myndex]

Hi @mraccess77 hi Jonathan,

Yes there certainly is not a perfect solution yet, but this is the closest I've found so far. Did you try dynamic mode and the CSS customization features under developer tools?

[jake-abma]

@Myndex @alastc Our application is behind a login, tried to check the Polymer-project but the new site doesn't use web components anymore... :-)

I see some old pages from polymer still have them, check out https://polymer-library.polymer-project.org/3.0/api/elements/dom-if as an example, the main context / text...

[Myndex]

I see some old pages from polymer still have them, check out https://polymer-library.polymer-project.org/3.0/api/elements/dom-if as an example, the main context / text...

Hi @jake-abma

Works fine for me. Dynamic mode does have an issue with some text that inherits properties from #shadow-root, I think can be adjusted but might be a bug that needs reporting.

Here are examples nevertheless that I did without editing any CSS at all. I made poor font and color choices intentionally to make the change obvious.

Dynamic and Light mode:

Filter+ and Dark Mode

Reasons a site may not work pasted from the docs:

The extension doesn't work at all
If you have similar dark mode extensions installed, disable them, reload tabs. Click Dark Reader icon, check if top-right button is set to On. Open Site list tab, check that Not invert listed is selected. If nothing helps, something terrible has happened, e-mail us.

The website is displayed incorrectly or works slow
Please, send the website address, screenshot, your OS and browser versions to our e-mail. We will try to investigate the reason, at least for a popular website. Also try changing theme generation mode or try using Light mode. Check that website is not listed under Site list tab.

The extension doesn't work in incognito mode
Open chrome://extensions page, find Dark Reader, click Allow in incognito.

The extension doesn't work for local files
Open chrome://extensions page, find Dark Reader, click Allow access to file URLs.

Entire website is not displayed in Filter mode
If you are using Chrome for Mac OS, update Mac OS up to 10.13, this should update your video drivers. If you are using Firefox, this is most likely a browser bug, use another mode for such websites.

[Myndex]

HI @Myndex I tried the extension but it doesn't really give me the granularity for colors that I want. It makes contrast better but changes the color combinations to ones that I don't prefer in some areas but ones that are pleasant in others. These filter approaches tend to be like that.

hi @mraccess77 Hi Jonathan,

Here's a link showing how to be very granular:

https://github.com/darkreader/darkreader#using-dev-tools

[JAWS-test]

Note 6 in contrast ratio

WCAG conformance should be evaluated for color pairs specified in the content that an author would expect to appear adjacent in typical presentation. Authors need not consider unusual presentations, such as color changes made by the user agent, except where caused by authors' code.

contradicts note 4 in my opinion, because the problem described in note 4 only occurs if the user excludes the colors in the user agent. It is possible that note 6 should be amended to refer only to changes made to the user agent that were not made by the user.

[jake-abma]

Hi Andrew, indeed it works fine, no idea why but I surely had issues first time I tried. Cheers!