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 w3c/wcag#2 and w3c/wcag#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 #187.
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.