Update term "contrast ratio" for SC 1.4.11

[JAWS-test2]

Contrast requirements also apply to non-text content in accordance with SC 1.4.11. Therefore "text" has been replaced by "content".

If no colors are defined, the notes for foreground and background apply.

[Myndex]

Objections:

1. Font smoothing and anti-aliasing applies primarily to fonts, so adding "non-text" to that paragraph is not particularly helpful.

ALSO: that entire paragraph should be deleted IMO, because authors can and unfortunately DO use things like "webkit-font-smoothing: antialias" which destroys the contrast. The use of webkit smoothing is a particular problem today, especially with WP templates, and authod imposed font smoothing definitely SHOULD be discussed.

2. Adding "If no foreground color is specified, then black is assumed." is incorrect. Text is NOT to be assumed to be black. Common defaults are black, blue for link, and red/purple for visited link.

But this is another paragraph that makes an assumption and should be deleted or revised. White should not be assumed to be the background. The default background is TRANSPARENT. So if you have text on a DIV with no BG color set, that div will be transparent and the color thus whatever random object it is over.

AND

Also this paragraph is in conflict with the later paragraph that says "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 color is specified, because the user's default background color is unknown and cannot be evaluated"

😳

Best Regards,

Andy

[JAWS-test]

I understand some of your objections. But I am not sure if you also have objections to the current version of the WCAG at this point. If so, perhaps you can make a suggestion on how it could be improved

[alastc]

@patrickhlauke will review. It might help to minimize the changes as this is normative text.

[bruce-usab]

Those six notes attached to the definition are unchanged from 2.0. I agree it was a missed opportunity not to update the notes when 1.4.11 was added.

There is also the long standing F24 Failure ... due to specifying foreground colors without specifying background colors or vice versa.

[bruce-usab]

I am okay only with the word substitution for note 2 (changing text to content).

IMHO, it is better for notes 3/4/5 to remain unchanged and specific to text.

[patrickhlauke]

while the sentiment/idea is valid - that it's not just text but also non-text content, it's not possible to turn off anti-aliaising for things like SVG or CSS lines etc. And even for text, it's not always possible - depending on OS or user agent - to turn it off even for text rendering.

[patrickhlauke]

instead of just "with anti-aliasing turned off", this may need to be expanded to something like

Suggested change

	evaluated with anti-aliasing turned off.
	evaluated with anti-aliasing turned off or ignored.

[patrickhlauke]

as 1.4.3 and 1.4.6 are specifically about text, there's no sense here changing things to be more generic

[TestPartners]

The phrase "the contrast ratio can be evaluated with anti-aliasing turned off" is ambiguous because it allows the measurement to be made using with the author-specified colours or the actual rendered colours. Is this ambiguity intentional? I think we should mandate one method or the other, unless there is a good reason not to.

Mandating the use of the author-specified colours would ensure consistency in measurements even if it doesn't reflect the user experience. I am inclined to favour this approach.

Allowing the measurement of the rendered colours introduces inconsistency and potentially allows testers to choose which colours to pick to get the result they want, which may be either a pass or fail. Furthermore, anti-aliased text often changes colour as the zoom level is changed.

[patrickhlauke]

@TestPartners so long story short, you're saying the definition should change "can" to "should"?

Or something more substantitve? note that understanding docs already mention that you should refer to author-defined values (from a recent-ish change that caused no end of arguing back and forth at the time)

https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
https://www.w3.org/WAI/WCAG22/Understanding/contrast-enhanced.html

Note

Because authors do not have control over user settings for font smoothing/anti-aliasing, when evaluating this Success Criterion, refer to the foreground and background colors obtained from the user agent, or the underlying markup and stylesheets, rather than the text as presented on screen.

Due to anti-aliasing, particularly thin or unusual fonts may be rendered by user agents with a much fainter color than the actual text color defined in the underlying CSS. This can lead to situations where text has a contrast ratio that nominally passes the Success Criterion, but has a much lower contrast in practice. In these cases, best practice would be for authors to choose a font with stronger/thicker lines, or to aim for a foreground/background color combination that exceeds the normative requirements of this success criterion.

[patrickhlauke]

Suggested change

	(for example font smoothing or anti-aliasing), the contrast ratio can be
	(for example font smoothing or anti-aliasing), the contrast ratio should be

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	67cef5c
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/6818dfc1bafed40008db8888
😎 Deploy Preview	https://deploy-preview-1018--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[patrickhlauke]

also, more generally, agree that the second and third note could probably do with being killed off altogether (about assumptions to be made about default foreground/background colours, and then saying that it's a failure if background isn't defined ... because it's a throwaway that doesn't actually go into sufficient detail, and makes it sound like every time you define foreground you must define background on that same element ,,, which is incorrect, since it's fine as long as at the very least the root/ancestor has things defined. also, why say in a definition that "it fails", as this is not in an SC but just defining the term itself)

[TestPartners]

@TestPartners so long story short, you're saying the definition should change "can" to "should"?

Or something more substantitve? note that understanding docs already mention that you should refer to author-defined values (from a recent-ish change that caused no end of arguing back and forth at the time)

Yes, that's what I'm saying, nothing more.

The Understanding document for SC 1.4.3 currently says "when evaluating this Success Criterion, refer to the foreground and background colors obtained from the user agent, or the underlying markup and stylesheets, rather than the text as presented on screen." I interpret this as MUST rather than CAN or SHOULD, and I think the same wording should be used for SC 1.4.11 to avoid ambiguity.

[patrickhlauke]

and I think the same wording should be used for SC 1.4.11 to avoid ambiguity.

note that the PR here is purely about the definition of "contrast ratio". changes to 1.4.11 understanding should be tackled separately (i have a vague feeling i may have filed something along those lines as a PR already somewhere)

[patrickhlauke]

Yes, that's what I'm saying, nothing more.

proposed here #1018 (comment)