-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes/corrections to 1.4.3 and 1.4.6 understanding #3020
Conversation
…less repetitive "here"
would be nice to squeeze these updates in (assuming they're accepted) in time for 2.2 final |
Hi Patrick @patrickhlauke
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 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. |
@Myndex I had a strong feeling that, just like saying "Candyman" 5 times while looking in the mirror, this thread would raise you... 🍬
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.
i'm sure @alastc can confirm, but ... this is NOT a "substantive change" for three reasons:
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 |
feel free to submit your own PR that fixes this, without changing any of the normative requirements, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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:
I'll make an edit to the PR here to adopt this style instead. |
…is is best practice only)
c300413
to
7a954d2
Compare
@detlevhfischer fixed/tweaked |
added commas for minor editorial changes for readability
same trivial punctuation changes as in other file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice adjustments. Improves existing non-normative guidance.
…ithub.com/w3c/wcag into patrickhlauke-understanding-text-contrast
@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? |
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:
Also:The statement (which is also in the original):
This is not true. There is CSS 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, |
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.
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.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(1) Typo. (2) The required values might not be "default" values if there is a conforming alternate version.
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. |
Co-authored-by: Mike Gower <[email protected]>
Co-authored-by: Mike Gower <[email protected]>
Matches the anti-aliasing notes we recently included for 1.4.3 and 1.4.6 (see #3020) --------- Co-authored-by: Mike Gower <[email protected]> Co-authored-by: David Cox <[email protected]>
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:
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?)ppi
(as a unit of measure) lowercase and without preceding space<code>
for code-y things (measurements, formulae)in the process, this also removes some broken and incorrect links in 1.4.6 understanding (e.g. link to "resources" that was borked)