RE: Color contrast below 4.5:1 in subset of browsers and devices - WCAG pass or fail?

> No, as arguably high contrast mode is only available in windows on IE/Edge/Firefox and no other browser?

As an FYI -- Firefox on macOS allows you to turn off page colors and use system colors/choose your own colors.  Essentially this allows the user to create their own high contrast theme with colors they choose and replace the page colors.

Jonathan

-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk> 
Sent: Wednesday, May 29, 2019 9:56 AM
To: w3c-wai-ig@w3.org
Subject: Re: Color contrast below 4.5:1 in subset of browsers and devices - WCAG pass or fail?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On 29/05/2019 13:21, Mark Rogers wrote:
> Ok, that makes sense, but what about these:
>
> 1) Does it mean you can document High Contrast Mode as "relied upon" to pass 2.3.1? If so, doesn’t that render the contrast checkpoints useless?

No, as arguably high contrast mode is only available in windows on IE/Edge/Firefox and no other browser?

> 2) In the presence of CSS parsing errors, colours may turn out different between browsers, or different versions of the same browser. For example, on this CSS WG test page:
> http://test.csswg.org/suites/css21_dev/20110323/html4/uri-013.htm

> IE11 - all lines have a green background Chrome 73 - some lines have a 
> red background, others have green background Firefox 48 - all lines 
> have a green background Firefox 67 - some lines have a red background, 
> others have green background Safari 9 - some lines have a red 
> background (but not the same red lines as Firefox 67)
>
> It's seems less clear that relying on parsing quirks is a 'relied upon' technology and 4.1.1 Parsing doesn't apply here since CSS isn't a markup language. There are rules for handling errors in CSS, but these changed between CSS 2.1 and 3.0 and are less consistently implemented than the HTML error handling rules.

Pass...this really goes into how accurately you test stuff, in what browser combinations, and beyond just pure WCAG assessment and into browser compatibility testing. If I discovered issues like this, I would fail them under the relevant SC. Others may pass this nominally. I'm sure in general everybody would agree that "it's a problem", the gray area is whether it's a hard fail or not...

> 3)  What happens if the contrast only falls below threshold at certain screen sizes or screen orientations. For example:
> @media ( max-width: 400px ) { input { color: #eee, background: #fff; } 
> @media ( orientation: landscape ) { input { color: #eee, background: 
> #fff; } That doesn’t seem to quite fit 'relied upon' definition and the orientation query also interacts with 1.3.4 Orientation.

Noting in WCAG 2.1 there's the new "Full pages" requirement which touches on variations of the same page based on width (arguably, orientation - which is triggered by the ratio of width to height - falls under this as well) https://www.w3.org/TR/WCAG21/#cc2 - so yes, all of these need to pass for the page to pass.

> 4) What happens if an @supports rule breaks contrast in a specific browser:
> @supports ( -moz-box-align ) { input { color: #eee, background: #fff; 
> } This passes if you can rely on something not being implemented, but 
> it's difficult to see how the 'relied upon' wording fits this 
> situation
>
> 5) What happens if the failure doesn't occur in older browsers because they don't support a specific technology like CSS gradients:
> input { color: #eee, background-color: #000; background: 
> linear-gradient(45deg, : #fff, : #fff); } Can you 'rely upon' an older implementation for conformance?

There's probably an aspect of reasonableness here about which old browsers / cutting edge features / etc can be relied upon / count as "accessibility supported"...likely there are many different takes on this, even within the working group.

> I guess the problem I'm driving at is the contrast problem can occur in lots of different ways, and it's undesirable if the same problem sometimes passes and sometimes fails depending on how it's implemented, even though the impact on the user is the same.

WCAG does not provide normative answers to all of these scenarios at the moment. And since WCAG is fairly cut and dry / binary, it's not ideal for these sorts of things that require reasonableness and nuance, sadly...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 29 May 2019 15:55:14 UTC