JAWS-test
commented
2 years ago I think 2 decimal places won't help, as even 4.4999 would be too little, although it can be rounded to 4.50. Therefore a note in the Understanding would be more meaningful
Closed julezrulez closed 2 years ago
JAWS-test
commented
2 years ago I think 2 decimal places won't help, as even 4.4999 would be too little, although it can be rounded to 4.50. Therefore a note in the Understanding would be more meaningful
bruce-usab
commented
2 years ago I have seen color combinations more than a few times which work out to 4.49:1, so I get where you are coming from. Personally, I would not want to be in the position of trying to defend that as not being good enough under high-stakes adversarial circumstances. Adding a couple decimal points implies a mathematical precision that is not warranted. I would be more in favor of going the other way, using 9:2 instead of 4.5:1 — but either edit would be a heavy lift, so not worth it IMHO.
+1 to the idea to suggest an edit for Understanding.
patrickhlauke
commented
2 years ago when you define a particular value as a minimum, i'd have thought that it's implied that you can't round up to it.
instead of adding something to the understanding document, it may make more sense to add another note to https://w3c.github.io/wcag/21/guidelines/#dfn-contrast-ratio (as otherwise we need to look at adding the same note to understanding in 1.4.3, 1.4.6, 1.4.11)
patrickhlauke
commented
2 years ago 
alastc
commented
2 years ago Thanks for the reference Patrick, it looks like this issue was raised before and the conclusion was to add these: https://github.com/w3c/wcag/pull/248/files?diff=split https://github.com/w3c/wcag/pull/247/files?diff=split
Given those are already there, it didn't prevent someone asking again. However, I'm not sure that adding something to the definition is going to prevent this in future either?
We also aren't likely to change the normative text.
Proposed response:
Thanks for raising this issue, it helps to know where people misunderstand aspects of the guidelines. There is already information in the understanding documents about this aspect if you need to reference something.
We can also take it as input to WCAG 3.0, where a different approach is being proposed for assessing text contrast.
However, at this stage of WCAG 2.x we do not wish to adjust the success criterion text.
patrickhlauke
commented
2 years ago ah, forgot what the actual follow-up was on those. seems like it's also worth adding the same/similar note to non-text contrast and possibly use of color understanding as well? if yes, i can tackle that in a separate PR @alastc
julezrulez
commented
2 years ago Thanks for your responses. It's almost clear to me. I understand that changing normative text is difficult. (The normative text however is where we measure accessibility with, so that text should be precise in that.). I can live with the text being put into the understanding documents. The text in the pull requests are clear enough.
That raises the question where I can find the proposed texts. I expected to find it here: https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html Also in the WCAG 2.0 documentation I could not find the text.
patrickhlauke
commented
2 years ago hmmm, indeed. I can't find those notes from the diffs @alastc referenced anywhere ...
Have those changes somehow fallend between the cracks? Should I make a new PR that reintroduces the agreed notes from those diffs to 2.1 / 2.2 ?
patrickhlauke
commented
2 years ago Made a pull request to resurrect those missing notes (and to also add one to 1.4.11 Non-Text Contrast) https://github.com/w3c/wcag/pull/2254
guyhickling
commented
2 years ago From a mathematical point of view, 4.49 is less than 4.5, as any accountant or maths school teacher will confirm. That any decimal amount from 4.45 up to 4.49999 rec. can be rounded up to 4.5 doesn't change the fact that they are all still factually less than 4.5. So the SC doesn't need to be made more precise, it already is precise.
However there is the slight issue that if you test with a colour contrast tool that shows the ratios to more than one decimal place, such as WebAIM's tool, you could get a ratio of 4.47 to 1, for example, and the tool would fail it. Whereas another tool inputting exactly the same colours but calculating to only 1 decimal place, would produce a ratio of 4.5 to 1 and pass it! But that is down to the colour contrast tools, and changing the wording of the SC would not alter this gotcha.
Testers need to be aware of this discrepancy between tools, however, and allow for the fact that the developer may have used a different tool to them. For instance if you are using WebAIM's tool, and you find some text is between 4.45 and 4.49 to 1, don't be ruthless and fail it, because you are likely to upset the designer or developer if they have tested their work to ensure it is 4.5 to 1 using the tool they normally use! My advice would be to just ignore a case like that; in any case there is no practical difference between two colour contrast values that are so close. Human eyes are not sufficiently sensitive to detect such minor contrast differences, so it would be somewhat pointless to report a defect for that!
patrickhlauke
commented
2 years ago tools that do rounding before comparing to the threshold are, of course, broken/wrong ... but sadly yes, it's likely not uncommon.
as a side note, in CCA , when precision is set to just one decimal point, it shows "just below 4.5:1" and fails when the non-rounded result is between 4.45000 and 4.49999 (or whatever the actual precision of our calculation is)
personally though, i'd say that colour contrast is one of the few SCs that has a mathematical, cut and dry pass/fail criterion. while i agree it feels petty to fail when it's just a tiny fractional bit below 4.5:1, just letting it slide does the evaluation a disservice - for once, when the pass/fail criterion is quite clear, it'd be good to actually stick to it (but of course, in the grand scheme of things, such a failure is almost trivial and super low priority...)
alastc
commented
2 years ago I can't find those notes from the diffs @alastc referenced anywhere
Michael has identified a short window when some updates to 2.0 didn't make it through a 'platform transition' (going from XML to HTML). They should appear soon.
patrickhlauke
commented
2 years ago Michael has identified a short window when some updates to 2.0 didn't make it through a 'platform transition' (going from XML to HTML). They should appear soon.
probably then worth rebasing https://github.com/w3c/wcag/pull/2254 as it does make the further addition of the note for 1.4.11 (and tweaks the wording ever so slightly in the notes)
Myndex
commented
2 years ago Considering that the WCAG 2 contrast math for 1.4.3, and other SCs relating to contrast, is not perceptually accurate, it essentially does not matter—it's splitting hairs on the floor of a barber shop.
Nevertheless, rounding down is usually bad because 4.50 to 1 is so often insufficient as it stands.
4.50 to 1 is not enough for blocks of body text with fonts smaller than 24px, even for a very light background. For dark text, with a background darker than #bbbbbb then 4.50 is grossly insufficient. WCAG 2 math can not be used for "dark mode".
Usually it should be encouraged to INCREASE contrast above 4.5:1, the exception being white text on a darker color background, as WCAG 2 contrast math does not calculate that correctly, either.
My point is that concerns about rounding here are not particularly relevant. Designing to "terget 4.5:1" is not best practice in the first place. Here's an example of 3:1, 4.5:1 and 7:1 against a perceptually accurate method:
Side note: the font sizes shown are the minimum sizes specified in the guideline for the method, this applies for all APCA Lc contrast levels as shown, and for WCAG 2 at 3:1, however WCAG 2 has no minimum font size for 4.5:1 AA or 7:1 AAA, so a common used font size was set in those cases.
patrickhlauke
commented
2 years ago @Myndex while i share the "it doesn't really matter in practice" idea, the fact remains that currently, WCAG 2.x is the standard that people use, and the standard that is referenced by many legislations around the world. so, until such time as your super duper new algorithm is a stable standard, and referenced by those pieces of legislation, it does matter to have an unambiguous interpretation...
Myndex
commented
2 years ago _...while i share the "it doesn't really matter in practice" idea, the fact remains that currently, WCAG 2.x is the standard that people use, and the standard that is referenced by many legislations around the world. so, until such time as your super duper new algorithm is a stable standard, and referenced by those pieces of legislation, it does matter to have an unambiguous interpretation..._
Hi @patrickhlauke
That's not the point I was making Patrick. The point I was making is that it's functionally irrelevant to talk about concerns of rounding the hundredth digit for a ratio that is ultimately incorrect, when the best practice is to use/target substantially MORE contrast than that for fonts under 24px. Body text should be at 10:1, and that's not even mentioned in WCAG 2 though it is in ISO. There are more viable standards out there than WCAG2.
The fact that it's law in Finland is not terribly relevant. In Australia, it is law for level A, which does not include 1.4.3, and the fact that it is "referenced" by legislation for government sites in many nations is interesting but notwithstanding. It's amusing to note that here in the US, even the DOJ's website has 1.4.3 fails, despite what they recently stated regarding accessibility.
The law in the United States per ADA is to "be accessible" — and true you can choose to adhere to WCAG 2 contrast, OR you can adhere to being functionally and actually accessible, i.e. using a perceptually accurate method (of any type, and there are many). Even the 508 has a specific section that states an alternate means may be used. And I've seen such an "equivalence" statement in other laws that I have investigated.
Or to be less snarky, which would you advise your clients to adhere to? Which is actually better for readability and accessibility? Which is most "super duper"?¹
Exceeding the law is "more better" than "super-duper". Bridge-PCA is completely backwards compatible with WCAG_2, and is a literal drop-in replacement for WCAG2 math that instantly transforms 1.4.3 into a useable SC, and meets and exceptionally exceeds AA or AAA, and has further AA and AAA enhanced criterion that further exceed 1.4.3 and 1.4.6, respectively.
Thank you Patrick,
A
Footnote: 1) It doesn't have to be APCA, it could be any of the other perceptually accurate maths, the reason I use APCA to compare, is those are the examples I've created most recently, and APCA is tuned for readability on displays.
patrickhlauke
commented
2 years ago There are more viable standards out there than WCAG2
sure, but this issue here is about WCAG 2.x and to make sure it's unambiguously defined, for those people who want/have to use WCAG 2.x. Thanks though.
Myndex
commented
2 years ago ...Thanks though.
It is a waste of time and effort, and further propagates an error that is causing functional problems and needs to be redacted in full.
GreggVan
commented
2 years ago Thanks Jules You are correct
But I believe that this is exactly why we should leave it as 4.5:1 and. 3:1.
And we should add in the understanding document that standard rounding should apply — so that. 4.45. would pass. This is indistinguishable from 4.5 to any human - and leaves us without getting into hair splitting. Also 4.50:1 is very unconventional and hard to read.
So - I think you point out a very correct problem — but I suggest we fix it in a different way. This also does not require that we create an erratum for the old guidelines — and avoids questions about why it is different - that requires more explanation and talking about math (not everyone’s strong suit)
All the best
G
On Mar 7, 2022, at 7:31 AM, Jules Ernst @. @.>> wrote:
I still have argues about contrast just under 4.5:1. For instance 4.49:1. I have had math several decades ago. I have learned there the following rounding rules: if numbers are written as 4.5 than this could be 4.45 through 4.54. So when measuring things, it should be very clear that contrast of 4.49 is almost right (which actually means that contrast fails).
So I propose to change the texts of this success criterion, like for instance:
"The visual presentation of text and images of text has a contrast ratio of at least 4.50:1, ...:" "Large-scale text and images of large-scale text have a contrast ratio of at least 3.00:1;" (changed text is marked by bold)
This might save a discussions with devs and avoid mistakes in advance.
— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2251, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXVQFJMODPR335NOZQTU6YOONANCNFSM5QDUJJDQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.
patrickhlauke
commented
2 years ago And we should add in the understanding document that standard rounding should apply — so that. 4.45. would pass
If you have a minimum threshold value that's hard-set, you can't "round up to it" and claim to pass. that's not how thresholds work.
Myndex
commented
2 years ago ...as even 4.49999 would be too little,...
$$ 0.9\overline{999} = 1.0 $$
You might say that rounding must be to some specific precision, but to say you can't round at all is nonsense! The precision available when using a computer to calculate decimal values requires rounding.
If you want to say that two decimal places is required, that's a different matter, however, that is not specified anywhere in the SC, and I see this thread spawned a PR a few months ago that put a "can't round" into the understanding document for 2.1, but again without specifying a precision.
As I stated earlier in this thread, and I will repeat, I object to this change as rounding is a required operation in floating point math on a computer, and otherwise this ignores a basic tenet of mathematics.
The PR and update to the SC's understanding does not specify a specific precision (number of decimal places), and all of this is aside from the fact that, as I pointed out above, is not particularly relevant for a method that is not perceptually uniform, and I'll stop there.
Finally, the PR was merged without survey, only an unsupported statement that "it was agreed on in 2016 but the notes from that time can not be found".
Also, for those that don't believe that $0.9\overline{999} = 1.0$ here are links to some proofs and discussion:
https://polymathematics.typepad.com/polymath/2006/06/no_im_sorry_it_.html https://www.themathdoctors.org/frequently-questioned-answers-0-999-1/
bruce-usab
commented
2 years ago And we should add in the understanding document that standard rounding should apply — so that 4.45. would pass.
Contrary to conventions used by mathematicians, this question was raised on a (relatively) recent AGWG call and the decision was that no, 4.4999 is not a pass. I will see (but not today) if I can find that in the minutes.
This [4.45] is indistinguishable from 4.5 to any human - and leaves us without getting into hair splitting. Also 4.50:1 is very unconventional and hard to read.
I agree on both points, but (if my recollection is correct) that was not the consensus of AGWG.
Myndex
commented
2 years ago Hi Bruce @bruce-usab
Contrary to conventions used by mathematicians,
_this question was raised on a (relatively) recent AGWG call and the decision was that no, 4.4999 is not a pass._
As stated, this conjecture is not well supported by math or science as I indicate in my previous post. It is also insignificant in effect and this organization has substantially more challenging problems to solve than to suddenly introduce a new condition relating to potental legal compliance that did not legally exist less than year ago.
Nevertheless, a supportable statement would be along the lines of "...to a minimum precision of two decimal places". Though AFAIC, rounding to a single decimal place is sufficient as the actual functional problems with the underlying math are not at all solved with this new conditional limitation.
patrickhlauke
commented
2 years ago now, we can agree that in actual practice, it's pointless to argue over whether or not in practice something at 4.45:1 is visually distinguishable from 4.5:1 or not. of course it's not, to a normal viewer. it was always a fairly arbitrary line in the sand, but one that is needed to be able to make a binary pass/fail call on things.
of course in WCAG 3 we'll have the all singing, all dancing new more accurate/aligned with actual human perception algorithm. great. in the meantime, we needed to remove the ambiguity in the wording of the SC, which we did with the PR that explicitly says "no rounding".
now whether 0.999 recurring (noting that i didn't talk about recurring myself) is actually mathematically 1, or whether deep in the internals of computes of course everything gets rounded eventually anyway, are "angels on a head of a pin" discussions, in my view. and, as you say, there are much more important problems to discuss/work on ... so why are we revisiting this topic AGAIN?
Myndex
commented
2 years ago so why are we revisiting this topic AGAIN?
Because the change is incorrect and inappropriate Patrick.
If you want to say that the result must be accurate to two decimal places of precision such as 4.50:1, then it is still not correct to just state "no rounding". The statement would need to be (in this example) "rounded to no less than two decimal places of precision." Though I will show that only one decimal place is needed, below.
we needed to remove the ambiguity in the wording of the SC, which we did with the PR that explicitly says "no rounding".
That does nothing to "remove ambiguity" as there was no ambiguity to begin with.
4.5:1 is not at all ambiguous. It clearly states a value with an implicit precision and is more than adequate, clear, and unambiguous. The mere stating of "no rounding" only means that instead of using Math.round() the code uses Math.floor() and the change is insignificant in terms of actual result but significant in terms of legal meaning.
The actual difference is only a single code value in one color channel.
#767676 vs #767776
There is no functional or visible difference, period. 4.5:1 is not ambiguous when rounding is used, as that is simple, well established, standard mathematics and already employed in contrast tools everywhere.
I would rather not make this a formal objection, so I will not at this time. But this change in inappropriate for a document where backwards compatibility is mandated and where there is intent and even some progress elevating this document into law.
If there was an ambiguity, it might be the case of 3:1, 7:1, it would be useful to state that "precision must be rounded to no less than one decimal place", i.e. 3.0:1. That is in effect a limit of 2.95:1 and the difference is similarly invisible.
Just saying "no rounding" without specified precision is not unambiguous and not appropriate, and in the land of 8bit and human vision, more than one decimal point is meaningless, as demonstrated.
Thank you for reading.
patrickhlauke
commented
2 years ago That does nothing to "remove ambiguity" as there was no ambiguity to begin with.
some people argued that 4.45:1 would pass, while others argues that 4.5:1 as minimum means that anything below that exact value is a fail. so yes, there was ambiguity, if you want to have an binary pass/fail that gets the same result regardless who runs the test
patrickhlauke
commented
2 years ago standard mathematics and already employed in contrast tools everywhere.
CCA doesn't do rounding. AxeCore doesn't do rounding. etc
patrickhlauke
commented
2 years ago I would rather not make this a formal objection
you'd rather not formally object to a decision taken in 2016? ok...
Myndex
commented
2 years ago _some people argued that 4.45:1 would pass, while others argues that 4.5:1 as minimum means that anything below that exact value is a fail. so yes, there was ambiguity, if you want to have an binary pass/fail that gets the same result regardless who runs the test_
As I stated, the appropriate and functionally correct cure is:
patrickhlauke
commented
2 years ago As I stated, the appropriate and functionally correct cure is
feel free to submit a PR
alastc
commented
2 years ago Because the change is incorrect and inappropriate Patrick.
There's been no change.
Adding a decimal place would just move the issue of rounding a place to the right, the argument is then whether 4.49 (or 4.449?) gets rounded up.
People could have interpreted it either way, so we've added which way to interpret it. We can move on now, I think the proposed response is still appropriate.
Myndex
commented
2 years ago There's been no change.
Thank you @alastc I disagree for the reasons stated.
Adding a decimal place would just move the issue of rounding a place to the right, the argument is then whether 4.49 (or 4.449?) gets rounded up. People could have interpreted it either way, so we've added which way to interpret it.
I DO understand the need to specify this unambiguously.
As I stated, my issue was with the content and manner of the clarification. Pull request #2726 clarifies in terms of what is actually needed from a maths standpoint, that being the definition of the minimum desired precision. I demonstrated above that one decimal point of precision is adequate.
is then whether 4.49 (or 4.449?) gets rounded up
From a math perspective, in a world of 8 bit per color, and also that of human perception, there is no difference between 4.49 and 4.5
There is no more than one code value difference in one color channel (green in mid range) between 4.449 and 4.5, which is also below human perception and therefore inconsequential in the defined use case.
EDIT FOR CLARITY: 4.449 does not round to 4.5 if we are stating one decimal place precision, but it is at the effective threshold for 4.45 which would round to 4.5, the reason I mentioned it as an example is that 4.449 is still only a code value and not perceivable.
Thank you for reading
bruce-usab
commented
2 years ago Above I wrote:
I will see (but not today) if I can find that in the minutes.
LOL, as Alastair notes, formal reply is already in this thread. The Calls Are Coming from Inside the House
patrickhlauke
commented
2 years ago LOL, as Alastair notes, formal reply is already in this thread
the problem here, of course, is that a proposed formal reply was made over 7 months ago, but never agreed/formalised, and the issue has remained open.
it then remained in limbo for the last 6 months, until @GreggVan reignited the discussion 14 hours ago...
bruce-usab
commented
2 years ago Here is the comment in the 2016 issue thread 200 closing this question and the minutes from the related AGWG call.
Does anyone object to updating Understanding to acknowledge that AGWG explicitly wants 4.5:1 to be treated as threshold, and yes, we are not following the usual mathematical convention?
alastc
commented
2 years ago The understanding doc already has that, bottom of the green note.
bruce-usab
commented
2 years ago @julezrulez if you find the discourse in this thread a to be sufficient explanation, please close this issue.
julezrulez
commented
2 years ago It is now clear for everyone how to handle rounding. See the notes of: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html
I still have argues about contrast just under 4.5:1. For instance 4.49:1. I have had math several decades ago. I have learned there the following rounding rules: if numbers are written as 4.5 than this could be 4.45 through 4.54. So when measuring things, it should be very clear that contrast of 4.49 is almost right (which actually means that contrast fails).
So I propose to change the texts of this success criterion, like for instance:
(changed text is marked by bold)
This might save a discussions with devs and avoid mistakes in advance.