AW: F24 - contrast

Hi all,

yes. Firefox and IE allow users to override all given css colors but not bg
images. The overriding of bg images (they are not visible) is happening
automatically when Windows OS are used and afaik just when Windows OS are
used. This 'behaviour' of Windows is covered in F3 (see the note). 

The overriding of all colors either in browsers like FF or IE or system-wide
for example with the Windows high contrast mode and the two SCs of WCAG 2.0
for contrast are reflecting imo the needs of different groups of people with
visual disabilities. Some visual disabilities - for example Retinitis
Pigmentosa (RP) - are leading to light and/or glare sensitivitiy. Some other
visual impairments or disabilities make it hard to discriminate colors when
contrast is not sufficient for the person, but not in a way that own color
schemes are needed.

What about other formats?

All examples of F24 are referring to HTML-pages. My personal opinion is that
F24 should not be a failure as long as we speak about FF and IE with their
possibilities to override all css colors with one more click in the settings
or Windows high contrast mode. But I also think that it needs a deeper look,
because not all browsers allow users to override all css-colors and probably
it is still a failure when using other OS than Windows. Which I think has to
be tested. If this would be the case (I can't check the HTML-examples in
other OS) probably the failures will be failures but would need a lot of
notes for different user agents.

Ramón brought in different formats and I think this is an important aspect
which is not covered explicitly in F24 at this moment. 

Just short (ok, hopefully short ;-) ) and when we think about PDF. When
switching Windows high contrast mode on it has no effect on the PDF itself
just on the menu and the bookmarks (Adobe Reader). PDF Readers like Adobe,
Foxit and the new VIP-Reader are coming with options for own color schemes
and/or high contrast mode(s). 

BUT: The contrast mode in Adobe Reader is not a success story, cause it is
not simply not working well. Sometimes the entire PDF appears black/black,
sometimes 'just' parts of the PDF appearing black/black. Which is in
documents I've tested not happening when using the contrast mode of for
example Foxit-Reader or VIP-Reader. 

Finding out under which circumstances a document appears (partly)
black/black in Adobe Reader seems to be a puzzle or a Sisyphus task.
Sometimes it seems to lie in the used typeface (embedded correctly or not),
sometimes the reason lies in the used list-points and sometimes it seems to
be the combination of list-points with the Word-Version used before
converted. 

In the last months I've tested around ten PDF where this happens in Adobe
Reader in Foxit-Reader. Not one of the tested documents failed in the
contrast mode of Foxit-Reader.

 So if F24  covers also PDF the question is: what could under these
circumstances be the testing procedure? A PDF might not be testable in Adobe
Reader - not because of specified colors but probably because of the
typeface, some of used types of list--points and ???? but it might not fail
in Foxit-Reader and/or the new VIP-Reader. 

In case the whole text appears also in Adobe Reader's contrast mode, what
happened with a PDF when colors are specified? I've tested a small text
written in Word 2010 with following colors: paragraphs in blue, orange,
automatic and  purple and converted the text to PDF. I've made the test
under the following scenario and with Adobe Reader and Foxit Reader:

- Windows high contrast mode (default, which is white text on black
background): ON - before opening the PDF 

- Accessibility options in Adobe Reader and Foxit Reader: use windows color
scheme

- Result for Adobe Reader: All text is white with black background

 - Result for Foxit Reader: automatic text is white with black background
and all colored text is grey on black ("only change the content" has to be
deactivated)

So: Under this scenario defining the color of a text or using automatic has
no effect in Adobe Reader and a "small" effect in Foxit Reader.  It works
fine in both PDF-Readers (as long as a text is visible in Adobe Reader's
contrast mode)  when using "automatic", which I think is not what F24 is
about.

There are of course other possible testing scenarios. This just for to show,
that the result depends on the Reader, which is - if PDF is covered by this
failure - tricky when it comes to the testing procedure of the failure.

Hope this all makes sense

Cheers 

Kerstin


--------------------------------------------------------------------
Kerstin Probiesch - Freie Beraterin
Barrierefreiheit, Social Media, Projektleitung 
Kantstraße 10/19 | 35039 Marburg
Tel.: 06421 167002
E-Mail: mail@barrierefreie-informationskultur.de
Web: http://www.barrierefreie-informationskultur.de
XING: http://www.xing.com/profile/Kerstin_Probiesch




          


Von: Adam Solomon [mailto:adam.solomon2@gmail.com] 
Gesendet: Donnerstag, 12. Dezember 2013 15:53
An: rcorominas@technosite.es; David MacDonald; Gregg Vanderheiden
Cc: WCAG
Betreff: Re: F24 - contrast

Firefox and ie (and perhaps others) allow the user to override css colors
AND bg images - so does that mean that to fulfill the criterion an author
would simply have to use a technology which works in modern browsers? (even
if the css colors failed the contrast ratio) - essentially saying that we
don't have to check contrast on web pages anymore

On Wed, Dec 11, 2013 at 8:39 PM, Ramón Corominas <rcorominas@technosite.es>
wrote:
Hi, David and all,

Windows high contrast mode changes any foreground colour to the selected
"automatic" text and any background colour to the selected automatic
background colour (remember that Windows has different high contrast modes,
not all of them use dark backgrounds).

In any case, links are not changed to the automatic foreground colour, but
to the default link text, which sometimes can provoke difficulties.
Nevertheless, most users of high contrast that I know also change this link
colour to meet their needs, either in the operating system or in the browser
itself (browsers usually have an option to override system colours).

However, in technologies different from HTML, colours are not managed the
same, and for example Word 2010 changes foreground colours to "automatic",
but leave background colours as defined by the author, which in many cases
provoke "white over light gray"; in addition, I think Adobe Reader does not
change any colour unless the reflow option is used.

So, if the Failure only applies to HTML, then it should probably be removed,
but if it applies to any technology, it is still valid.

Regards,
Ramón.


David wrote:

> The history of this is to enable users to *switch* colours (black to
> white and vice versa) without the hard coded colours preventing then
> change... so it black switches to white in the background but the
> foreground doesn’t switch then you have black text on black
> background... this is one of those success criteria that we will want to
> look closely at, because as far as I can tell AT that switches colours
> such as zoomtext will override even hard coded colours and successfully
> make the change, We would have to check Windows high contrast mode, but
> I think it does the same thing... so I question whether we should
> continue to fail it...
>
>
>>
>> is F24 - http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/F24
>>
>> a failure even if the actual contrast meets the minimum contrast
>> requirement ratio? In other words, if an author were to specify black
>> text color in css (and left the default background-color of say white)
>> where the ratio meets the success criterion de facto, would this still
>> fail since no bgcolor was specified in the css (because the user could
>> run into problems if he did choose a different default background color
>> in his browser settings)?

Received on Saturday, 14 December 2013 10:38:58 UTC