Changes/corrections to 1.4.3 and 1.4.6 understanding

[patrickhlauke]

The understanding documents for 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) currently contain various small errors, incorrect links/references, a few throwaway non-sequiturs, some unnecessarily duplicated content, and are not harmonised. Key changes include:

• add a new note (inspired by the note that was in 1.4.6) about thin/unusual fonts and antialiasing and what to actually do as an author
• remove the weird inconsistency of talking about "thin or unusual", and in the next part of the sentence "fancy or thin" (also... "fancy"? really?)
• harmonise capitalisation of "Success Criterion"
• in 1.4.3, removes the whole start of the "Rationale" section which is an exact copy of the end of the "Intent" section? reorders that section to be more logical
• remove the very odd It is sometimes helpful for authors to not specify colors for certain sections of a page... statement. it comes out of nowhere, is arguably incorrect, but then doesn't explain itself further either (so why exactly is this supposedly helpful? when should I as an author know when to do this or not?)
• some code cleanup (removing excessive line breaks, sorting out some excessively long single lines
• use of ppi (as a unit of measure) lowercase and without preceding space
• use of <code> for code-y things (measurements, formulae)
• harmonise 1.4.3 and 1.4.6 understanding

in the process, this also removes some broken and incorrect links in 1.4.6 understanding (e.g. link to "resources" that was borked)

[patrickhlauke]

would be nice to squeeze these updates in (assuming they're accepted) in time for 2.2 final

[Myndex]

Hi Patrick @patrickhlauke

The understanding documents for 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) currently contain various small errors

Those understanding documents contain some very large errors as well. Not to mention unsupportable misunderstandings.

I'm not gonna make any jokes about painting a burning house (or am I?) but one question I have relates to commit number d1ef550 which seems to be a substantive change, and I bring this up because I was informed that we can't make substantive changes? Or can we? Because the understanding needs a massive ton of substantive changes to make it relevant and actually truthful, which presently it is not.

For instance the statement made in this particular commit d1ef550 is essentially negated by the note that states that "authors may turn off anti-aliasing when testing"

Thing is, as I'm sure you are well aware, I agree with you with this change that you suggest making. After all I've been writing about this problem (anti-aliasing and thin fonts) as one of the key readability problems for the last four years.

And anti-aliasing is definitely something that's within control of the author through the related CSS properties, and is frequently misused and abused.... Along with far too thin fonts, which were not common in 2007 when everyone was just using plain web fonts and black #000000 text.

Can we do substantive changes?

Perhaps this is a better question for Alastair @alastc ???

Since this pull request of yours (Patrick) includes some substantive changes relating to meaning, intent, and understanding, I'd like to know to what extent substantive changes can be made to understanding documents here?

This document could be re-written substantially, while keeping the SC 1.4.3 as it stands, and at least improve understanding and help get rid of the poor misunderstandings that appear to stem from this document. Now, I understand there will be no change to the actual math or thresholds at this time—but getting rid of misunderstandings, hand-wavy pseudoscience 'splaining, and the inherent "reciting facts not in evidence", would be a step in the right direction.

While I have no interest in spending the time and effort to do so if I'm ultimately going to be told that it's simply not possible to make such changes, nevertheless in reviewing this PR, I reread that document and I can best describe it as listening to nails on a chalkboard to me, and it makes me immediately think of basic changes that are needed.

Thank you for reading.

[patrickhlauke]

@Myndex I had a strong feeling that, just like saying "Candyman" 5 times while looking in the mirror, this thread would raise you... 🍬

I'm not gonna make any jokes about painting a burning house

We've had this discussion many times before, but: until WCAG 3 comes out in 20XX, for better or worse, WCAG 2.x will still be what authors have to care about (section 508 in the US still references WCAG 2.0, the european EN 301 549 still references WCAG 2.1, and even if they adopt WCAG 2.2 coming out soon at some point, this will still be referencing 1.4.3 and 1.4.6 for a good few years to come). So while I appreciate that for you it's all about APCA ... where the rubber meets the road, in the here and now of accessibility auditing and legal requirement, this is what auditors and authors need to work with, so any clarification of our currently valid documentation will have immediate benefits that will be directly felt by folks in their daily work.

but one question I have relates to commit number d1ef550 which seems to be a substantive change, and I bring this up because I was informed that we can't make substantive changes?

i'm sure @alastc can confirm, but ... this is NOT a "substantive change" for three reasons:

1. it's in the understanding document, which is informative/non-normative
2. it does not define any change in how authors would evaluate a pass or fail. it suggests that as a best practice (i.e. not normatively, not required to pass the SC, but clearly a suggestion of going beyond what the normative requirement is) authors should consider what to do if they do have particularly thin/unusual fonts that result in a visually lower contrast than what the pure numbers evaluation would lead you to believe
3. the subject matter of that note was already present in both 1.4.3 and 1.4.6 understanding, and in 1.4.6's it already hinted at this suggestion more directly... so it's not a new aspect. this change here just makes it clearer what this actually means for authors, makes a best practice suggestion, and then harmonises this across both 1.4.3 and 1.4.6

For instance the statement made in this particular commit d1ef550 is essentially negated by the note that states that "authors may turn off anti-aliasing when testing"

no it's not, because the note in this PR is a best practice recommendation (not normative), while the "authors may turn off anti-aliasing when testing" note is specifically about how to do the normative evaluation.

in essence, my note follows on from that with some non-normative/informative advice ... "so, you turned off antialiasing, evaluated the pure foreground/background numbers to get to the contrast ratio...however, you ARE using thin/unusual fonts which in practice will have a much lower ratio, so what do you do? you still pass if on paper the contrast was fine, but as a best practice, consider either using a different font or exceeding the ratio a bit, to make this actually work for users in the real world regardless of whether or not 'on paper' you're passing the SC". if you don't, hey that's cool, it was only a best practice suggestion. you do you, just know that you're not actually doing your real-world users any favours...but you are passing WCAG

[patrickhlauke]

getting rid of misunderstandings, hand-wavy pseudoscience 'splaining, and the inherent "reciting facts not in evidence", would be a step in the right direction.

feel free to submit your own PR that fixes this, without changing any of the normative requirements,

[detlevhfischer]

All good stuff.
The only thing I wasn't sure about was the use of "we":
"we recommend as a best practice", "we suggest" etc. Can't remember whether that kind of "we" is common in understanding texts.

[patrickhlauke]

@detlevhfischer

The only thing I wasn't sure about was the use of "we"

ah, good catch. yeah, this is probably coming more from the sort of thing I (we) write in my audits for clients...I tend to use this phrasing for best practices in those cases, and it bubbled over into this 😄

Having a quick peek at existing parts of WCAG, this is the way best practices are generally introduced:

• A best practice is to ... (from 2.5.3 Label in Name)
• Best practice is to ... (from F24)
• The best practice is to ... (from G83)
• The best practice would be to ... (from 3.2.4 Consistent Identification understanding)
• It is a best practice ... (from 2.4.4 Link Purpose (In Context) understanding)

I'll make an edit to the PR here to adopt this style instead.

[patrickhlauke]

@detlevhfischer fixed/tweaked

[mbgower]

Nice adjustments. Improves existing non-normative guidance.

[patrickhlauke]

@mbgower made a further addition to the note about anti-aliasing 03427af as this aspect (how to actually evaluate regardless of antialiasing) was not clear, and the note https://www.w3.org/TR/WCAG21/#dfn-contrast-ratio "the contrast ratio for text can be evaluated with anti-aliasing turned off" makes things potentially more confusing/misleading - can rather than should of must?

[Myndex]

the contrast ratio for text can be evaluated with anti-aliasing turned off" makes things potentially more confusing/misleading - can rather than should of must?

Hi Patrick @patrickhlauke

I'd rather not say "must turn off anti-aliasing", because while that might be permitted it is definitely not best practice.

The problem that I have with the way it was originally written, is that turning off anti-aliasing is ** almost a way of cheating** (except that I think it's unlikely that people use the eyedropper method). But the point is, turning off antialiasing before using an eyedropper does not serve the user need for accessibility, because it allows for a situation where the ultimately rendered font with anti-aliasing on, is at a much lower perceived contrast than the low contrast that's already permitted WCAG 2.

From the draft guidance in the readability guidelines we're working on, when using an eyedropper tool to sample:

• The eye dropper tool must report the native CSS value for the color space (nominally sRGB).
• The eye dropper sample should be a pixel in the middle of a major stroke of the thinnest weight/smallest size font to be tested, and with the content at the default size (no zoom or scaling).
• 
• For small and thin fonts, where the major stroke is inconsistent due to antialiasing, sample at least three to five different letters and average the result.

Also:

The statement (which is also in the original):

"...Because authors do not have control over user settings for font smoothing/anti-aliasing...."

This is not true. There is CSS -webkit-font-smoothing: for macOS, which allows direct modification of anti-aliasing features, and text-rendering: for Windows and Linux which affects anti-aliasing control to a degree.

A problem with saying that authors don't have control is that it removes those considerations from being tested for, but IMO should be.

In particular, -webkit-font-smoothing: is often abused to a very poor effect, meaning unreadable text. If somebody is using -webkit-font-smoothing:, the font weight needs to be substantial enough to handle the blending to the background that -webkit-font-smoothing: causes.

[patrickhlauke]

I'd rather not say "must turn off anti-aliasing", because while that might be permitted it is definitely not best practice.

it is in terms of testing against the terms of the SC as it was created and as it stands now. the SC never took into account anti-aliasing, smoothing, etc. for evaluation purposes, it relies on checking the color values as defined in the code. which yes, we know is not actually useful in the real world, but that's what we have to work with. given that reality, then having a handwavy "can" in a definition is even more confusing.

This is not true. There is CSS -webkit-font-smoothing: for macOS, which allows direct modification of anti-aliasing features, and text-rendering: for Windows and Linux which affects anti-aliasing control to a degree.

to a degree, perhaps, but not consistently. and that's the main point: since what I as an evaluator may see if i color-pick on my computer with my browser/OS/user settings may be different from what another evaluator sees on their machine, we may end up with different results where one of us passes something, and the other person fails it. which is not ideal for consistency.

also, that phrasing is in the glossary/definitions, which are normative, so changing that will be a world of back-and-forth pain to approve and push through a normative change to WCAG...so I left it as is, despite its slight inaccuracy.

A problem with saying that authors don't have control is that it removes those considerations from being tested for, but IMO should be.

in the context of these two SCs in WCAG 2.x, smoothing and antialiasing were never part of the testing considerations, and that's not going to change.

[mitchellevan]

(1) Typo. (2) The required values might not be "default" values if there is a conforming alternate version.

[Myndex]

in the context of these two SCs in WCAG 2.x, smoothing and antialiasing were never part of the testing considerations, and that's not going to change.

Hi @patrickhlauke

Hi Patrick I just want you to know that I do appreciate you taking the extra time to reply to me, and point out where I misinterpret various aspects of these documents. Thank you.