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

Thanks - I suspected that might the case due to the wording. 

The logical outcome is you can have two controls on a page, with identical colours and the same poor contrast when displayed by some browsers, but one is a WCAG failure and the other isn't a failure. The example below displays two identical poor contrast fields in Firefox/IE, but only one is a failure.

It's possible to modify this example so that all input fields have poor contrast in Chrome/Safari/Edge, but good contrast in Firefox and IE. That means about 90%** of users see the poor contrast version, but that's probably not a WCAG failure since Firefox is multi-platform and meets the definition of 'widely-distributed user agent'. 

**Firefox + IE combined market share is about 10% on https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-timeseries.


I don't think there's any way round this with the current normative text, but this might be a useful test case for WCAG.next when checking for undesirable outcomes.

<!doctype html>
<html lang="en">
<head>
    <title>Test</title>
    <style>
    body {
        color: #000;
        background-color: #fff;
    }

    /* contrast ratio 1.18 */
    input.fieldA, input.fieldB {
        color: #ddd;
        background-color: #ccc;
    }

   /* contrast ratio 21.0 - the :read-write selector is a relied upon technology - doesn't work in Firefox/IE, so both fields have 1.18 contrast in Firefox/IE */
    input.fieldB:read-write {
        color: #000;
        background-color: #fff;
    }
    </style>
</head>
<body>
    <p>
        <label>Fails WCAG - low contrast in all browsers, unless CSS is disabled or High Contrast mode is on  <input type='text' class='fieldA' value='low contrast text'></label>
    </p>
    <p>
        <label>Passes WCAG - low contrast in some browsers, unless CSS is disabled or High Contrast mode is on  <input type='text' class='fieldB' value='low contrast text in Firefox/IE '></label>
    </p>
</body>
</html>

Cheers
Mark

-- 
Mark Rogers - mark.rogers@powermapper.com
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
 



On 29/05/2019, 15:01, "Patrick H. Lauke" <redux@splintered.co.uk> wrote:

    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 Friday, 31 May 2019 16:56:53 UTC