Text has enhanced contrast - Passed example 7 + clarification

[giacomo-petri]

While reviewing pull request #1904 I noticed passed example 7:

This text has the default browser text color on the default browser background color. By default this is black text on a white background, which has a contrast ratio of 21:1.

Some text in a human language

In particular

By default this is black text on a white background

with the introduction of dark/light mode, now this might not be always true.

Moreover, in this scenario, colors might be defined by the user and they are no longer an author responsibility. Basically, it's currently passing, but not really because the contrast ratio is always sufficient.

Should we add some language somewhere better explaining this scenario?

Some possibilities:

• remove from applicability test targets with background and foreground colors not specified and move passed example 7 in inapplicabile
• add some language in expectation, clearly stating that test targets with not specified background color and not specified text color are passing
• simply removing "By default this is black text on a white background, which has a contrast ratio of 21:1." (I'm still thinking this might not be enough clear without some context).

---

One more clarification, just to be sure I've properly understood the specific rule expectations:

For each test target, the highest possible contrast between the foreground colors and background colors is at least 7:1 or 4.5:1 for larger scale text, except if the test target is part of a text node that is purely decorative or does not express anything in human language.

is it intended to say that the following example is currently passing because the highest possible contrast between the foreground color (#333 dark grey) and background color (#FFF white) is 12.63:1, even if half letter has a contrast ratio of 1.66 (#333 dark grey on #000 black)?

Thanks

[Jym77]

For the first part (user styles, or preferences), this is essentially handled in the definition of the CSS input aspect:

The test cases of ACT Rules interested in the CSS styling must be viewed with the CSS included by the author, and the user agent default style sheet. User style sheets and other custom styles should be avoided to ensure test cases have the expected outcome.

See also #1654 for discussions that lead to that solution.

The key point is that the rule does not care about the origin of styles. It is only the example that break in presence of user styles. So, changing the rule to require that the colours have author origin (which is easy for CSS properties since origin is a thing but would get more tricky for background images) is not really needed.

---

For the second point, yes, the rule passes such a case. Which, as always, doesn't imply that the SC fails (rule passes => further testing is needed). It proved very hard to correctly define what shapes of white background around the black letter would be enough (e.g., a slim "border" in the same shape, even without the "hole" in the A might be enough 🤔). OTOH, if all surrounding background is bad, then the text is bad for sure. So the rule stayed conservative and only flag the cases where we can be sure contrast is bad.

[giacomo-petri]

Thanks @Jym77 for clarifications. Everything is clear.

I'm still just "concerned" about the quoted sentence:

This text has the default browser text color on the default browser background color. By default this is black text on a white background, which has a contrast ratio of 21:1.

For example, my Safari in dark mode has a white text over a black background, which is the opposite of what's written here (without changing any preference). That's why I've suggested to simply clarify that the reason why the rule is passing is not because the default colors are black for text and white for background, and consequently, their contrast ratio is 21:1, but because both background and foreground colors are not specified by the author (removing the "By default this is black text on a white brackground, ...").

This will be always valid regardless the technology used.