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

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 13:56:16 UTC