WCAG20/Institutional Memory/SC 1.4.3

Institutional Memory input for SC 1.4.3:

There was a ton of debate about number of color combinations that would be available. There was a group that wanted 4:1 and a group that wanted 5:1, and 4.5:1 was the compromise.

This is one of the success criteria that has the most well-documented research behind it. There was still lots of debate about exactly what ratio to use, as well as exactly what formula.

As discussed in the Understanding document, the ratio is aimed specifically at people with some vision impairment. For some people, this level of contrast is a problem and makes it harder for them to read. There is no one-size-fits-all for color, and allowing color customization is a crucial user agent function.

Similar issues come up for diagrams and images as for text, but the demands of diagrams and images are so much harder to meet that we didn't think we could come up with a success criterion. Hence the recommendation that people try to provide similar contrast, but no conformance requirement.

BBailey: I made one of the strident arguments for 9:2 over 5:1. We wanted a simple ratio, and the research just about evenly supported either, but obviously 5:1 was better in that it required more contrast. I argued that the main problem with 5:1 is that it eliminates almost all tri-color schemes (for example, black and white text against a gray background) for what might be a rounding error.

MichaelC: Recent discussion made it obvious to me we don't collectively have clear memory of the difference between luminosity and hue, which are both components of color (along with saturation). While hue is relevant to color perception issues, there is no simple universal rule for how to make accessible perception. That's why we went with luminosity (brightness, lightness) contrast, which is more straightforward. We chose levels that were achievable for authors and should help most users, and more strict (but difficult to meet) levels at AAA. The hue and saturation component are completely excluded from the calculation.

Also note that while WCAG picks out luminosity / brightness / lightness as the element of interest, which fits with the HSB color model, other color models can be converted to HSB for purpose of evaluating WCAG. So the color model itself isn't relevant.

One thing we didn't sort out very well is how the calculation applies against a variable background, or when there is blurring / aliasing / border around text. Sometimes a border can increase perception of contrast, but sometimes it can further blend the foreground and background together. There have been questions of variable backgrounds, do you calculate every adjacent pixel, or the average value, or what? We've tried to come up with answers to comments on that but I think never really sorted that out for the guidelines.

======

I would say that it would not be a failure for either a mouse or a keyboard focus. Here is the rationale.

the purpose of high contrast is to allow it to be read. This is true for both the mouse and keyboard because the person can simply read it before focusing on it. They then focus on it and then activate it. It WOULD be nice if they could confirm it when selected -- but even with lower contrast they can probably still read it once they already know what it says. But either way, they can move off of it and read it - then move on to it and select it.

The alternative would be to require that it have enough contrast either way-- but then there might not be much difference between selected and not selected -- which would be more confusing and unusable for the person with low vision.

So I would say it was OK and in fact might be a better design than if it "selected" and "non-selected" both met the contrast rules. And I don't think it would technically fail the SC either.

(ive actually heard the problem in the reverse -- where it ONLY has sufficient contrast when pointed to or focused on . This happens because they want enough contrast between the link and the surrounding text and this causes a problem for people with color blindness where the color contrast is good but not the contrast overall. But there are combinations that work. )

( added the above comment to the issue in case it is of use to you (not the parenthetical comment - since it is of another case -- and might confuse things)

Interesting question.

Gregg

gregg

On Feb 17, 2014, at 8:41 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:

Gregg, Any thoughts on this? Obviously there is a workaround to low-contrast link text on-hover (e.g. move the mouse off the link) but I’d be interested in your thoughts as to whether this violates 1.4.3/1.4.7… AWK

From: Loretta Guarino Reid [1] Sent: Monday, February 17, 2014 9:27 PM To: Andrew Kirkpatrick Subject: Re: Link color

Hmm - I think this wouldn't be a problem, since the text can be read "normally" and the user should know what they are interacting with. It is the kind of thing that Gregg would have interesting insight on.

On Mon, Feb 17, 2014 at 6:16 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote: Loretta, What do you think about this: http://www.w3.org/2006/02/lc-comments-tracker/35422/WD-UNDERSTANDING-WCAG20-20140107/

My gut is that if this color change occurred when using the keyboard to focus the link that we'd call it a failure. Is it different if it just with the mouse?

Thanks, AWK