- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 29 Jul 2016 09:15:11 -0400
- To: Detlev Fischer <detlev.fischer@testkreis.de>
- CC: WCAG <w3c-wai-gl@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>, Alastair Campbell <acampbell@nomensa.com>
- Message-ID: <BLU437-SMTP55176F4117F3CE530B2BD5FE010@phx.gbl>
The colour contrast analyser has a way to make a bigger than 1 pixel sample.... Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.4902 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com <http://www.can-adapt.com/> * Adapting the web to all users* * Including those with disabilities* If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> On Fri, Jul 29, 2016 at 5:02 AM, Detlev Fischer <detlev.fischer@testkreis.de > wrote: > In testing, we often encounter text over photos which have some parts of > text with sufficient contrast, others not so. > The problem may be minor (just some small patches with insufficient > contrast). If the background is not largely uniform / blurred but > irregular, chosing the reference point for the colour picker gets > difficult. In many cases, picking the worst bit of background (as David > suggests) seems subjectively unfair if we are dealing with a small and > isolated patch. Its main benefit is that it is rule-like ("always go for > the point with the weakest contrast even if it is just one pixel wide"). > > Theoretically one could create a mix of bg colours (use Gaussian blur) to > get the 'average' bg colour but that would not account for the perceived > difficulties for reading on vivid backgrounds where the averaged value > would pass but the text is nevertheless hard to read. > > In sum: measuring contrast of text on photo backgrounds involves > subjective judgment. Tools help, but whether you pass or fail an edge case > around 4,5:1 will be down to your handling of the colour picker... > > -- > Detlev Fischer > testkreis c/o feld.wald.wiese > Thedestr. 2, 22767 Hamburg > > Mobil +49 (0)157 57 57 57 45 > Fax +49 (0)40 439 10 68-5 > > http://www.testkreis.de > Beratung, Tests und Schulungen für barrierefreie Websites > > Alastair Campbell schrieb am 29.07.2016 10:39: > > > JF: “the impact of Alpha Transparency of colors and the impact on color > > contrast and accessibility?” > > > > I guess this is mostly a matter of how it is measured? > > > > So if designer/developer specifies a foreground and/or background colour > with > > some transparency, you shouldn’t use the CSS defined colour to test > contrast > > without accounting for the transparency. (I know transparency is > generally > > defined with the colour, but that doesn’t mean a testing tool accounts > for > > it.) > > If the transparent colour of a box (the background for text) is on top > of a > > white background it will be lighter than on a black background, which > needs to > > be accounted for. > > > > However, if you use a tool with an eye-dropper style mechanism on the > resulting > > colours, that should be accurate. Unless I’m missing something? > > > > The contrast adjuster function in the CSS-color-4 spec looks cool (if > it’s > > implemented?), it references WCAG2 1.4.3 so should line up. > > > > Perhaps we need to make G18 more specific about testing the result > rather than > > the colour definition? > > > > And perhaps we could create a test page that would pass if transparency > is not > > accounted for, but should fail, and check that each of the tools listed > in G18 > > accounts for the transparency? (Perhaps the browser based ones don’t?) > > > > Cheers, > > > > -Alastair > > > > > > > >
Received on Friday, 29 July 2016 13:15:44 UTC