Rounding and Color contrast

[DavidMacDonald]

The color value #777777 is evaluated on some analyser tools as 4.5:1 (pass), and 4.48:1 (fail) on other tools on our resource list.
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-resources-head
Tests here:
http://davidmacd.com/test/check-color.html

The actual value appears to be 4.48.
https://twitter.com/jared_w_smith/status/751433009316794368

My personal opinion is that the SC wording of "at least 4.5:1" means it cannot be rounded up to the threshold from a lower number.

But this started quite a discussion on twitter with some saying that science, math and case law points to 4.48 passing... it is argued that because we only had one digit in the decimal 4.5:1 for the SC then any 2 digit value can be rounded up or down according to rounding practices.( i.e., 4.44 would round to 4.4 failing and 4.45 would round to 4.5 which is a pass.)

The minimum contrast value up until the last draft of WCAG 2 was 5:1. We reluctantly accepted 4.5:1 on the last draft recommended by the Access Board ... if we had stayed at 5 then the under the argued rounding reasoning, 4.5:1 would still pass because it it rounds up to 5:1.

Let's make a decision and put it in the Understanding. I suggest something explicit such as.

When this Success Criteria says "at least 4.5:1", it means this is the threshold, and that no number less than that can pass, even if it is rounded."

[pauljadam]

Can the normative SC wording write it out to the decimal place it's expecting folks to round? i.e. 4.50:1.00 and 3.00:1.00? Or something that is very specific about the rounding if you can round or not?

[DavidMacDonald]

Maybe in 2.1, but we even cringed at 4.5:1 instead of 5:1 which was the original in most drafts, adding more digits seems a little academic.

[awkawk]

I think that if you were in a dispute over this somehow that:

1. the rest of the site must be fantastic as this is a very minor difference
2. you would be asked to provide a scientific basis for the treatment of the numbers. 4.5, as written in WCAG 2.0 has 2 significant digits. To compare a number to it, in this case 4.48, you might subtract 4.5-4.48, which gives you 0.02, but since there can only be the same number of significant digits in the answer, the answer for the difference is actually 0. This would mean that 4.46 and greater (or even 4.456 if you have a tool that gives that number of decimal places) could be viewed as meeting a 4.5:1

We can be more prescriptive in the future, but given that the 4.5 value is based on a negotiation between people on the group who pushed for 4:1 and those who pushed for 5:1, I'm not sure that it will make a huge difference. We should be careful not to say 5:1 though, as with the significant figures calculations 4.56:1 would meet a 5:1 (1 significant figure) ratio.

[DavidMacDonald]

but since there can only be the same number of significant digits in the answer

Not sure why there has to be the same # of digits. There was no discussion of that in WCAG 2.

Historical background: Bruce at the Access Board requested 4.5 in the last months before WCAG 2 release. It was always 5:1 until then. The group didn't want to have a 0.5 digit, so a few discussed 4.0 which was quickly discarded. Lighthouse approved 4.5. Bruce created colour wheel. He and I took an action item to identify the extra colours between 4.5 and 5. We found significant new colours allowed, and the group decided to adopt it.

I've worked with companies that have spent $100,000 on their colors. This stuff is important to them. They are not in great humour if they should have chosen #767676 instead of #777777 after painstaking research to be on the threshold. http://davidmacd.com/test/check-color.html

I think we need to make a clarifying statement on what we intended when we said "at least 4.5:1"

There are tools that are in conflict with each other at the threshold because of rounding. One fails #777 the other passes it. Many organizations choose threshold colours, and are very upset it their colour passes one tool and not the other when both tools are on our list of recommendations. This is a math formula.

[Cliff-axs]

I'm curious: What was discussed when the decision about any value—3:1, 5:1, anything—was made? As I see it, there are four factors to consider here:

• Precision of the method. Best I can tell, the inherent imprecision in measuring luminance is a tad under 0.7 percent. That means that all those digits in the second decimal place are pretty shaky. For values around 3, the imprecision is ±0.02. For values at the level of AAA—7:1—the imprecision is about ±0.05. So if a calculated value is 2.98 or 2.99, we can't be absolutely sure that the right value for the property we are trying to calculate is not 3.00. Under these conditions, a scientist would probably keep that third digit, but would not make any life-or-death decisions based on its value.
• The fit between the model on which our calculation is based and the actual behavior of the properties we are trying to predict: luminosity, for one, and, more critically, the response of the typical human visual system—the eye, the nerves, the brain—to differences in luminosity. Here, there's a lot more slop than 0.7 percent. I don't know how to quantify it, other than to point out that 0.7 percent seems like nothing compared to the difference between vision with cataracts and vision with a perfectly clear lens. The very fact that the calculation must change when one parameter falls below a certain threshold is a strong indication that the fit between the model and reality is not perfect, and might well be far from perfect for certain color combinations. Honestly, does anyone in this discussion know enough about these factors to give us an idea of what is going on? Of where the calculation is more trustworthy and where it is less so?
• The whole point of having some threshold for luminosity contrast is to remove a barrier that hinders people with various visual defects from using the Web. In terms of the people affected—the people with disability who are affected, not the people who merely have age-related loss of acuity, as I do—in terms of those people, what is the significance of any given font size and any given number? Who are we including with 5:1 but screening out with 4.5:1? And if we do screen them out, what is their alternative for gaining access to the Web? We know that we cannot make everything perfectly accessible to everybody. When we set a standard, it would help if we could speak to the issue of the nature and magnitude of its impact on people. If we have had that discussion, can someone point me to it? This is particularly interesting to me because I have met people with low moderate vision who prefer very low contrast—below 3:1, actually. Other friends with low vision prefer contrast that is higher than 3:1, but not anything like the high-contrast alternative settings generally available in operating systems, browsers, and websites. A range of 4:1 to 7:1 or maybe 8:1 seems to work for them. People like me, whose aging eyes have more trouble making out small text on a monitor two feet from our faces, definitely appreciate contrast ratios of 9:1 or higher. Ours is a meta-disability. On the other hand, that level of contrast gives headaches to people who cannot make out the words and images without zooming way in and getting their eyes as close to the monitor as possible. Theirs is a disability. Of the two groups, whom is WCAG intended to serve best? I imagine their must be many people with visual disabilities who benefit greatly from high contrast—but where is the information that shows how the needs of various groups with actual disabilities were weighed in coming up with these thresholds? Whom are we helping? Whom are hurting? What are their alternatives? (Cliff can adjust his system fonts to 125 percent. Problem solved. I doubt that works well enough for people with low moderate vision.) What is the impact we are creating, for better or for worse, by setting this threshold where we have? I would expect a Certified Professional in Accessibility Core Competencies to be able to address that point eloquently. I'm still waiting for any one of our profession to do so.
• David was so gauche as to bring up the subject of money. $100,000? Chicken feed. If word around the shop was to be believed—and I have good reason to not doubt that word at all—a predecessor to A Titanic Telecommunications company I once worked for spent a 7-figure sum choosing just the right shade of orange to show the world who they are and what they stand for. It's called branding, and people who do it well are highly compensated. The right shade of green, and your detergent flies off the shelves. The wrong shade, and you're eating your inventory. It matters. I'll address two real implications for our work with people who do branding. First, choosing the "right" color. If the branding professional's education, experience, and talent say that a shade of color with a contrast ratio of 2.96 is the reddest or brownest they can let that orange without causing grievous harm, the way most of us interpret our standard for accessibility would force us to tell them to start over and find a different answer. In short, we truncate calculated values—we don't round. So even a calculated value of 2 followed by an infinite number of 9s to the right of the decimal would fail—even though I seem to recall proving in a couple of different ways over the course of my education that 2-point-repetend-9 and 3.0 are, in fact, the same quantity. Yes, Fortune 10 corporation, go spend another 7 figures on this exercise because my profession refuses to round. Second, the real impact of a decision. I have never heard anyone else mention this, but the highest luminance contrast ratio any color can have from both black and white is the square root of 21. That number is a shade under 4.59. So one impact of setting a contrast threshold to 5.0:1 is to tell every corporation in the world that they may not choose a branding color that they can use as both the background for black text and, when the background is white, as the color of the text. The number of colors we allowed to pass by lowering that threshold to 4.5:1 might be far less significant than the fact that a slender slice or two of the color wheel—those colors with a contrast ratio of between 4.50:1 and 4.67:1 to white (4.67:1 to white is 4.5:1 to black)—is now available to corporations that feel they need to be able to use their branding color against black in some instances and white in others. Admittedly, those impacts are not preventing people from gaining access to the Web. But the impacts are real in terms of their effects on the lives and careers of people in other professions.

So when I hear my colleagues say, "Of course we don't round," or "There are no measurements in the calculation. It is defined constants and RGB values, which are integers," I don't hear the well-grounded basis a profession should have for the standards it sets. David has encountered a professional dilemma—some tools round, some don't, the standard has only two significant digits, and the customer's branding professionals say they really need the color that will pass only if the calculated value is rounded.

How many people will not be able to use the Web if we let #777777 pass? What are the circumstances that close that opportunity to them? What alternative means of access exist?

We can't answer those questions—at least I haven't yet seen even one of us give it a try—but we're willing to tell David to pick up that phone or walk into that conference room and tell his client that for all the good it did them on the color scheme, they should have taken that $100,000 to Vegas, because the right answer is off by #010101.

If we really want to stick to that position, then at the very least it would behoove us to add the choice between these two colors to Understanding WCAG as an example to illustrate that when we say 3, 4.5, and 7, we mean that the value truncated to that degree of precision—one digit for 3 and 7; two for 4.5—must equal or exceed the threshold.

Consider this: Making online materials accessible begins with understanding your audience and their needs. David's audience was confused to the tune of a $100,000 mistake—and, by and large, the response I have heard from our profession has been, "The problem isn't with WCAG. It's with whoever decided to round."

In other words, "The tool didn't work for the user, so it's the user's fault."

Much as I like the people who have taken that position, I find the position itself abhorrent. It represents the antithesis of the purpose of our profession.

[DavidMacDonald]

Personally, I don't care which direction we go. But we need to make a decision and go with it. Let's simply say "yes rounding is OK" or "No it is not"

There are trolls who sue companies for failing WCAG. This represents real loss of $ for companies EVEN if everything that Cliff says is accepted by the court. But if the troll says "I used a tool listed by WCAG and it failed the colour for me" It complicates the issue, especially when some tools fail a threshold colour and others don't.

The other cost is the wasted hours trying to decide threshold colours. I'm working with a major company where these discussions have had to take place among very expensive consultancies.

Currently, I don't know whether to tell my client to change #777 or not. Debating it is a waste of my time and money as well.

Please, let's just make a decision and document it. Here's the new proposal.

"Normal rounding to the nearest 1/10th (0.1) which results in at least 4.5:1 is sufficient"

[alice]

I completely agree that being specific regarding rounding in WCAG sounds fairly important and urgent.

I'm personally in favour of explicitly allowing rounding because:

• The value differences are virtually imperceptible - a contrast ratio difference of (at most) 0.05 is extremely unlikely to be the difference between legibility and illegibility. There is a contrast ratio difference of 0.08 between the second last and last paragraph in this example (in fact, every paragraph is different from each other, except for the first and last paragraphs - the first paragraph is repeated in order to show the most "extreme" difference in contrast ratio).
• Furthermore, given the nature of RGB colors, it's extremely unlikely to find a color value which is right on the threshold; for example, altering one color channel by one bit in the example above causes the contrast ratio to change by 0.04, so it may be that the option beneath the threshold is significantly closer to it than option above the threshold even if only one bit is different.

I think if rounding were really likely to make or break legibility, we should pick a higher threshold and allow rounding against that.

[Cliff-axs]

Just a note: Do the calculation yourself, and you will find that all 7 of the color contrast checkers were rounding. Truncated to 2 digits past the decimal the actual value for #777777 against #FFFFFF is 4.47, not 4.48. (Taken as far as my calculator would go, it was 4.4780894535772137.)

So whether we know it or not, we have been rounding all along. I see this as a clear case where in Understanding WCAG we need to explicitly work through a specific example. To show whether to round, that example must be a case in which rounding changes the status.

Rounding should be allowed for this reason if no other: The value of 4.5 is based on an imprecise calculation. It was obtained by multiplying 3.0 by "roughly 1.5," a number based on the empirical measurement of the difference in contrast sensitivity between 20/20 and 20/40 vision. "Roughly" means that "5" in the tenths column is shaky, so the 5 in the tenths column of 4.5 is shaky, too. In principle, we should round, and we should round to the tenth. We don't know this world precisely enough to go farther.

Then we should also show some examples of enhanced contrast. Show the same text at 3.0, 3.8, 4.5, 5.8, 7.0, 8.5, and 10.0. (Actually, I wouldn't choose arbitrary values other than the thresholds. Instead, I would use the color schemes of the default UI of various phones and popular apps. Make it a real-world scenario.) Find the research, if it exists, to show the practical results of choosing various levels:

• At this level, what percentage of people with 20/70 vision can read large text? (Actually, the nature of the lack of acuity is more significant than the degree, so we should break this down by the type of visual defect.)
• At this level, what percentage of people with vision at or corrected to 20/20 can read a smartphone in full daylight at noon.

It's important to show the impact on people with 20/70 vision because our threshold of 4.5 is based on 20/40, which is approximately where age-related loss of acuity begins but not a relevant measure for disability. In the United States, at least, disability begins with low-moderate vision, which starts at a visual acuity that cannot be corrected to better than 20/70.

Doing so will accomplish four important goals:

• For people who use the guidelines and supporting documents as standards, clarify precisely what is called for.
• Illustrate to people who want to do better than barely passing what "better" looks like.
• Give everyone a better understanding of the impact of these decisions.
• Make it clear that the numbers cited in WCAG 1.4.3 and 1.4.6 are thresholds to be met or, preferably, exceeded, not standards to be met.

Most people just want to do what's best, but they need to know the answer quickly enough to meet a deadline. If we want them to embrace accessibility (or at the very least not to resent it), we need to create guides that are considerate of their needs.

[srinivasuchakravarthula]

If at all, we need to provide direction on rounding off, I think, it's OK to round-off. As Andrew mentioned above, anything above 4.46:1 would eventually meet 4.5:1. Reason I agree to round off is keeping practical scenarios in mind. Whether we like it or not, in the companies, it's hard to work with folks on design decisions. Since we are not compromising much lower than 4.5:1, I think rounding off would be OK. Practically, if designers comes back and ask how does it matter in ratio of difference of 0.02, we cannot argue every time. Also, asking for dot perfection to 4.5 would not always be accepted; when we talk about 0.02 etc.,

[WilcoFiers]

On yesterday's WCAG call there was a brief discussion on what to do with rounding of color contrast. I got an e-mail this morning with a very nice case that gives us the solution.

In axe-core we found a violation that had a contrast of 4.495447083. Axe-core doesn't round, so that ended up as a violation. But in the error message, it showed up as 4.50:1, which obviously confused the user. Given that none of the tools display more then 3 digits in the reporting of the contrast, and many of them only use two, it's probably best to do the rounding, so that nobody ever get's a violation like: "The color contrast ratio of 4.50:1 does not meet the required of 4.5:1".

[awkawk]

Upon further review of the rules of significant figures in calculations I'm changing my position on this. There is no doubt that 4.5:1 is restrictive and there can be an impact on design, but it does seem clear that the WG felt that the ratio was a threshold value.

http://www.w3.org/WAI/GL/2008/12/DIFF-WCAG20-UNDERSTANDING-20081211/#visual-audio-contrast-contrast
"(20/40 calculates to approximately 4.5:1[begin delete] which is rounded up to 5 providing a slight additional increase in contrast[end delete].)"

As a result, I'm suggesting adding a note to Understanding for 1.4.3 and 1.4.6 that clarifies that the value computed for the contrast should not be rounded, and then that value is compared to the reference ratio.

For example, if the measured/computed value is 4.4899 then you could compare 4.5 (2 signifiant figures) with 4.4989 (5 significant figures) and the answer is 0.0101 before considering significant figures and 0.010 after considering significant figures. Either way, the value doesn't meet the "at least 4.5:1" threshold.

In the case of the 3:1 ratio, if the measured value is 2.99 (2 significant figs) then 3-2.99 = 0.01.

The point of the significant figures in this discussion is that the mathematical purpose of significant figures is to ensure that the accuracy of an answer is appropriate when there are different levels of precision in the values being compared.

The simplest and most consistent answer for implementers is to treat the ratio as a threshold, in my opinion.

Pull requests:
https://github.com/w3c/wcag/pull/248/files?diff=split
https://github.com/w3c/wcag/pull/247/files?diff=split

[alice]

@awkawk Did you read my comment above explaining that changing a single color channel by a single bit may cause the contrast ratio to change by as much as 0.04? It seems like we should have a similar granularity in the measurement as we do in our ability to affect it.

[awkawk]

I did, but we aren't in a position to change the text of the SC, and to apply a variation like that in the interpretation isn't supported in the original discussions of the group so that would need to wait for a change in the normative document itself.

[mraccess77]

I vote for no rounding.

[awkawk]

Commits updated per the WG call:
https://github.com/w3c/wcag/pull/248/files?diff=split
https://github.com/w3c/wcag/pull/247/files?diff=split

[awkawk]

Accepted by CfC: https://www.w3.org/WAI/GL/wiki/Decisions

[bruce-usab]

I am glad to be remined today that we came to consensus on this detail! One note to OP is that recommendation was not from Access Board per se, just me at the time (as staff at the Access Board, sharing my opinion). As David recounts, the main concern I raised then is that 5:1 precluded all black:something:white and 9:2 provided some (but just two pure grays). The math was defensible, but the other concern raised at the time was that there were few participants in the single clinical validation study; that made the rational tenuous for picking one value over the other.

[Myndex]

Rounding is not only correct, it s mathematically necessary. "Not rounding" does not fix the significant problems with WCAG 2 contrast math.

But the point is, one can't just say "no rounding", it is necessary to define the number of digits of precision. In this case, one decimal place is sufficient, two is more than enough, and three is needless overkill with no functional benefit.

[GreggVan]

In standards — rounding is allowed beyond the specified level So if the spec is 5 you can round 4.1 or .2 etc (tenths) If the spec is 5.0 you can only round hundredth 4.01 4.02 etc If the spec is 4.5 ditto - you can only round hundredths 4.51 4.52 etc Really good specs say whether .5 rounds up or down (usually standard for that standard group) Gregg Vanderheiden ***@***.***

…

On Oct 11, 2022, at 9:58 AM, Andrew Somers ***@***.***> wrote: Rounding is not only correct, it s mathematically necessary. "Not rounding" does not fix the significant problems with WCAG 2 contrast math. But the point is, one can't just say "no rounding", it is necessary to define the number of digits of precision. In this case, one decimal place is sufficient, two is more than enough, and three is needless overkill with no functional benefit. — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQVKPVIW22VUNNKUJLWCWMB3ANCNFSM4CJA6FHQ>. You are receiving this because you are subscribed to this thread.

[patrickhlauke]

so @GreggVan ... you saying that 4.45:1 passes the minimum of 4.5:1? if so, then we'll need to revisit this discussion for 2016...

[Myndex]

Hi @GreggVan

So if the spec is 5 you can round 4.1 or .2 etc (tenths)

I'm a little confused: I would never round 4.1 up to 5 (unless ceiling was specified), but I would commonly round 4.5 up to 5 if no precision was specified, if that is what you mean?

I just posted PR #2726 which I believe addresses the issue, stating that rounding must be to a precision no less than one decimal place, i.e. 4.45 can round to 4.5 but 4.44 can not, or 2.95 can round to 3.0

My understanding of rounding convention is a 5 rounds up, at least in the USA... I'm not sure I have seen many cases where a 5 rounds down, other than cases where "floor" is specified, or maybe some oddball cases where rounding is constrained to a nonstandard value.

Andy

[mraccess77]

This group already agreed to no rounding and all of the tools were updated the follow that. We should not be flip flopping.

[Cliff-axs]

We discussed the mathematical and regulatory significance of calculations and rounding before, and members of this community decided that the scientific facts were “pedantry” and “bullshit.” Still, I will try once more. When we use the formulas based on the RBG color system to define colors, we’re basically saying that there are 256 discrete steps from none of that color present (value = 0) to full saturation with that color (value = 255). In other words, we have applied a digital model (on or off, nothing in between) to a continuous function (the intensity of a light source of the selected wavelength). This is akin to the shortcomings of digitally recorded music: at some level, the smooth curve of sound recorded in vinyl, with all its intricacies and overtones, has been converted into a combination of step functions: Off or on, no in-between. Subtleties of a Joshua Bell vibrato are lost. Back to light: spread across today’s highest-resolution monitors, our 255-step gradation from no color to full saturation would look quite pixelated. I haven’t had my color vision tested, but I probably wouldn’t be able to tell. But there are a few among us who have extra structures in their eyes—structures that enable them to see millions of colors where I would see thousands. To them, that gradation of 255 shades across a monitor would look like the Capitol steps. Back to people: Here’s where it matters. What’s the impact on people? We have two to consider:• How many people can really see the difference between a color contrast ratio of 2.999:1 and 3.000:1? Or 2.95:1 and 3.00:1?• A designer in good faith chooses a color pair that the widely used tool says gives a contrast ratio of 4.5:1. But another widely used tool says, no, your tool actually rounded 4.48 up to 4.5. They come to the accessibility community and say, “What does this mean?” What did “we” say? We said, “You need to throw out your design and come up with a new color pair. If that means going back to all your stakeholders—focus groups, executive office, creative team, marketing, production, the CEO’s in-laws—and seeing whether pleasing them means a softer gray, a deeper blue, or both, then that’s what you have to do.” We never said, “Who will this affect? How seriously?” Some of us said, “Here’s what you do: put a one-pixel-wide line of very high saturation at the edge of the darker color and a one-pixel-wide line of a very low saturation at the edge of the lighter color. Then your calculation uses those colors, not the colors of your palette, and instead of failing with 4.48, you pass with something like 20.67.” People who know visual design well would tell us that’s bunk. Those pixel-wide lines don’t make the two regions easier to tell apart. They blur the edge. They create a situation worse than the problem they supposedly solved. We didn’t probe to understand the problem. We didn’t look into what solves the problem. We just came up with ways to change the number associated with the measurement—without even knowing whether the number needed changing at all. The problem here isn’t so much whether or not we round. (We don’t, but we should. If we mean 4.6 is high enough, we say so by making the spec 5. If we mean 4.94 is too low, we say so by making the spec 5.0. As Gregg said, that’s how the mathematics of standards works.) The problem here is that we all chimed in on a matter without having the background knowledge required to answer the question, and many of us shouted down the input of people who did have that background knowledge. We came to a frustratedly expedient answer. You know what the best answer is? A two-parter: 1. What Gregg says. Follow the practice of international standards. We’re professionals who want to be taken seriously, right? Then let’s be professional. 2. Those lines—3:1, 4.5:1, 7:1—are like the edge of the balance beam. The closer you get to them, the more likely you’ll slip up. Use them as guides, but don’t live right up against them. We need our message about design to take that approach. Because we aren’t talking about 4.5000000001 being perfect and 4.44444444444444449 being disaster. We’re talking about making our content imperceptible to a few more people each step we take down towards 4.5. So let’s realize 4.5 is the limit, and any number that rounds to it satisfies the law, but let’s encourage designers not to push those limits without having a good reason and without taking into account the fact that nearing the limit affects some of your audience.  Because, yes, our shades of gray have shades of gray, and we have to live with it. Cliff TyllickRetired Sent from Yahoo Mail for iPhone On Tuesday, October 11, 2022, 2:14 PM, GreggVan ***@***.***> wrote: In standards — rounding is allowed beyond the specified level So if the spec is 5 you can round 4.1 or .2 etc (tenths) If the spec is 5.0 you can only round hundredth 4.01 4.02 etc If the spec is 4.5 ditto - you can only round hundredths 4.51 4.52 etc Really good specs say whether .5 rounds up or down (usually standard for that standard group) Gregg Vanderheiden ***@***.***

On Oct 11, 2022, at 9:58 AM, Andrew Somers ***@***.***> wrote: Rounding is not only correct, it s mathematically necessary. "Not rounding" does not fix the significant problems with WCAG 2 contrast math. But the point is, one can't just say "no rounding", it is necessary to define the number of digits of precision. In this case, one decimal place is sufficient, two is more than enough, and three is needless overkill with no functional benefit. — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQVKPVIW22VUNNKUJLWCWMB3ANCNFSM4CJA6FHQ>. You are receiving this because you are subscribed to this thread.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[GreggVan]

First What wrote was round up or down with the midpoint (5) rounded up So if the spec was 5 Then 4.1 and 4.2 would round to 4 and fail And 4.5 and above would round to 5 and pass However if you set the spec to 5.0 then 4.94 would round to 4.9 and fail and 4.95 would round to 5.0 and pass And if you set the spec as 5.00 then 4.994 would round to 4.99 and fail and 4.995 would round to 5.00 and pass So we can decide how much precision we want (we obviously aren’t specifying anything to hundredths in our doc

…

On Oct 11, 2022, at 12:52 PM, Andrew Somers ***@***.***> wrote: Hi @GreggVan <https://github.com/GreggVan> So if the spec is 5 you can round 4.1 or .2 etc (tenths) I'm a little confused: I would never round 4.1 up to 5 (unless ceiling was specified), but I would commonly round 4.5 up to 5 if no precision was specified, if that is what you mean? I just posted PR #2726 <#2726> which I believe addresses the issue, stating that rounding must be to a precision no less than one decimal place, i.e. 4.45 can round to 4.5 but 4.44 can not, or 2.95 can round to 3.0 My understanding of rounding convention is a 5 rounds up, at least in the USA... I'm not sure I have seen many cases where a 5 rounds down, other than cases where "floor" is specified, or maybe some oddball cases where rounding is constrained to a nonstandard value. Andy — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXU764BRG46CIII3TX3WCXAQXANCNFSM4CJA6FHQ>. You are receiving this because you were mentioned.

[GreggVan]

IF we allow rounding - then yes If we do not allow rounding then No It is up to us if we want to allow rounding or not. We can also specify how much rounding we want to allow 4.5:1 without rounding allows 4.5000000000 and up to pass 4.4999999999 fails 4.5:1 with rounding allows 4.4500000000 and up to pass 4.4499999999 fails 4.50:1 with rounding allows 4.4950000000 and up to pass 4.49499999999 fails

…

On Oct 11, 2022, at 12:41 PM, Patrick H. Lauke ***@***.***> wrote: so @GreggVan <https://github.com/GreggVan> ... you saying that 4.45:1 passes the minimum of 4.5:1? if so, then we'll need to revisit this discussion for 2016... — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUM3JWSN2QW62GKZ73WCW7GJANCNFSM4CJA6FHQ>. You are receiving this because you were mentioned.

[Myndex]

Hi @GreggVan I thought that was what you meant but I wanted to clarify. And that is exactly how I phrased the corrected pull request.

I did not specify "rounding half point away from zero" but the examples II provided do demonstrate that.

[GreggVan]

Yes but you left the gap between 4.44 and 4.45

Andrew Somers ***@***.***> wrote: I just posted PR #2726 <#2726> which I believe addresses the issue, stating that rounding must be to a precision no less than one decimal place, i.e. 4.45 can round to 4.5 but 4.44 can not, or 2.95 can round to 3.0

and I know someone will say OK so 4.449 rounds to 4.5 right? And the answer is no. you don’t serially round. So I was proposing a simpler version that just says 4.45 or more rounds to 4.5 and passes and anything less than 4.45 rounds down to 4.4 and fails.

…

On Oct 11, 2022, at 3:43 PM, Andrew Somers ***@***.***> wrote: Hi @GreggVan <https://github.com/GreggVan> I thought that was what you meant but I wanted to clarify. And that is exactly how I phrased the corrected pull request. I did not specify "rounding half point away from zero" <https://www.calculatorsoup.com/calculators/math/roundingnumbers.php> but the examples II provided do demonstrate that. — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQ2DY7NO3ZQK3NOYWDWCXUQ5ANCNFSM4CJA6FHQ>. You are receiving this because you were mentioned.

[Myndex]

@GreggVan Well, I was trying to keep things to a single sentence or two...

Does there need to be an understanding note on how to round? I suppose perhaps there does.

[Cliff-axs]

If there is an “Understanding WCAG” note, it doesn’t need to be on how to round. It needs to be on how to use this guideline, which is written unlike any other measurement standard. The problem is that the W3C/WCAG community has decided to deal with the limits as if they have infinite precision and only values that fall favorably when truncated to the precision stated in the spec are acceptable. So any value that produces 3 or greater on truncation passes that success criterion. Any value that produces 4.5 or greater on truncation passes that success criterion. And the community does not care that one limit is stated to unit precision and the other is stated to tenth-of-a-unit precision. Because that’s math, and this is WCAG. CST Sent from Yahoo Mail for iPhone On Tuesday, October 11, 2022, 7:17 PM, Andrew Somers ***@***.***> wrote: @GreggVan Well, I was trying to keep things to a single sentence or two... Does there need to be an understanding note on how to round? I suppose perhaps there does. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[GreggVan]

Whether we round or truncate That part needs to be in the standard. And for 2.2 we should add that statement in the front end or the conformance or definitions. But it is ambiguous if not stated and we need to state it. Truncating might be easiest - and match current tools. But whichever - it needs stating. Gregg

…

On Oct 11, 2022, at 7:31 PM, Cliff Tyllick ***@***.***> wrote: If there is an “Understanding WCAG” note, it doesn’t need to be on how to round. It needs to be on how to use this guideline, which is written unlike any other measurement standard. The problem is that the W3C/WCAG community has decided to deal with the limits as if they have infinite precision and only values that fall favorably when truncated to the precision stated in the spec are acceptable. So any value that produces 3 or greater on truncation passes that success criterion. Any value that produces 4.5 or greater on truncation passes that success criterion. And the community does not care that one limit is stated to unit precision and the other is stated to tenth-of-a-unit precision. Because that’s math, and this is WCAG. CST Sent from Yahoo Mail for iPhone On Tuesday, October 11, 2022, 7:17 PM, Andrew Somers ***@***.***> wrote: @GreggVan Well, I was trying to keep things to a single sentence or two... Does there need to be an understanding note on how to round? I suppose perhaps there does. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXSTX2FRSWQY5FDD6DDWCYPHZANCNFSM4CJA6FHQ>. You are receiving this because you were mentioned.

[Cliff-axs]

Agreed. And it would help, too, if all of the numbers were expressed to the same precision—3.0, 4.5, and 7.0. Why? Because it might not mean anything at all to you, but it does mean something in the field of measurement. Stating the numbers to different precisions is confusing. It raises questions you think are answered. Just as you are careful in deciding which words to use in the guidelines—word by word, every single word—you need to be careful about how you present these numbers. To present one threshold to the tenth of a value (4.5) and two others as whole numbers (3 and 7) triggers questions in the minds of people schooled in measurement theory before they even begin to read the guideline. So present the numbers in a way that seems to make no difference to you because it does communicate different information to them. In short:• State the threshold as 3.0.• Refer to the calculation method.• Add this statement: “For the purposes of conformance, do not round the result of the calculation. That is, the first digit of the result must be 3. A result of 2.99 does not conform.” Repeat the statements for each threshold, using the corresponding values. A final word: When you dismiss these concerns as pedantic—or worse—you’re telling a colleague that you see no value in their expertise. If you want people to participate and contribute, treat them with respect. Cliff Tyllick Sent from Yahoo Mail for iPhone On Tuesday, October 11, 2022, 11:00 PM, GreggVan ***@***.***> wrote: Whether we round or truncate That part needs to be in the standard. And for 2.2 we should add that statement in the front end or the conformance or definitions. But it is ambiguous if not stated and we need to state it. Truncating might be easiest - and match current tools. But whichever - it needs stating. Gregg

On Oct 11, 2022, at 7:31 PM, Cliff Tyllick ***@***.***> wrote: If there is an “Understanding WCAG” note, it doesn’t need to be on how to round. It needs to be on how to use this guideline, which is written unlike any other measurement standard. The problem is that the W3C/WCAG community has decided to deal with the limits as if they have infinite precision and only values that fall favorably when truncated to the precision stated in the spec are acceptable. So any value that produces 3 or greater on truncation passes that success criterion. Any value that produces 4.5 or greater on truncation passes that success criterion. And the community does not care that one limit is stated to unit precision and the other is stated to tenth-of-a-unit precision. Because that’s math, and this is WCAG. CST Sent from Yahoo Mail for iPhone On Tuesday, October 11, 2022, 7:17 PM, Andrew Somers ***@***.***> wrote: @GreggVan Well, I was trying to keep things to a single sentence or two... Does there need to be an understanding note on how to round? I suppose perhaps there does. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXSTX2FRSWQY5FDD6DDWCYPHZANCNFSM4CJA6FHQ>. You are receiving this because you were mentioned.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>