Re: Specifying foreground and background colors

[dropped UA from distribution]

You can call it an accessibility issue by the following rationale:

At 09:07 PM 2000-06-13 -0400, Wendy A Chisholm wrote:
>At 12:59 AM 6/10/00 , Charles McCathieNevile wrote:
>>Assuming a particular colour combination is a user's default and that
>>therefore it is only necessary to specify colours for things that are not
the
>>default is a mistake.
>>(particularly for accessiblity reasons they may choose
>>something else, although there may be other reasons. I don't know that it is
>>a reason not to include the technique, as the way to specify thinigs
>>correctly.)
>
>My main question is not "should we include this as a technique."
>
>Rather, my question is, "what is the accessibility rationale for this 
>technique."  I did not see any, thus did not include any in my proposal.

If both foreground and background colors are set any time either one is
set, you are guaranteed that the contrast will be the contrast between the
pair desired by _someone_, not the random contrast between one color set by
someone and another color set by someone else.

Because the outcome of violating this rule is random color combinations not
designed by anybody, with sometimes poor contrast, it generates
inaccessibility when the contrast is poor and that is the accessibility
rationale.

Violating this rule creates an avoidable _risk_ of inaccessible color
pairings. 

Because people with disabilities are more likely to find the text illegible
by reason of the poor color contrast than are people with normal vision,
this may be regarded as an access defect and not just poor design.
Designers would mostly cringe at the thought of colors they picked being
randomly displayed in contrast against some other color picked artistically
but totally independently by somebody _else_.  So you wouldn't have trouble
selling this rule as a good design rule. 

You can still claim it has accessibility at stake because of the people
with vision impairments who could not resolve some of the random color
combinations that normal vision users would cope with.  Some of the bad
combinations that can occur will indeed wipe everyone out; but there are
all three kinds in the random distribution of results: contrast good for
all, contrast bad for all, and contrast that works for some but not for
all.  It is the content in the last case which is denied to the PWDs and
rationalizes calling this an accessibility issue.

[PS: the better part of valor is probably to leave the rationale in the
mail archive and not put all that level of casuistry in the document...]

This rule should be followed by both the author's stylesheet and the user's
stylesheet for maximum effectiveness.

Aha!  I guess that I have mostly thought of the WCAG as providing rules for
the author.  In this case there is a guideline for the CSS writer who is
the user or an access specialist assisting the user.  Had not thought of
the user's stylesheet as "web content" but we need a home for this advice
somewhere, don't we?


Al


>
>I think the rationale is "good design."  Regardless of whether I choose a 
>high-contrast background and foreground color combination (white and dark 
>red), if the user only selects a foreground color (white) current user 
>agents will not select a high contrast background color.  They will display 
>the author set background color (white) and the user set foreground color 
>(white).  The user will have to select a foreground color as well.  In some 
>browsers, the user could select "high-contrast mode" where the browser 
>selects both the foreground and background colors.  For example, yellow 
>text on a black background.
>
>>Maybe we should ask the ER or UA groups to look in more detail at the issue
>>of ensuring contrast? Most User Agents allow a choice of colours, although
>>most do not automatically pick a contrasting colour where there is a
conflict
>>or semi-specified colour scheme.
>
>I think this is a UA issue and have CC'ed the UA working group.  Chris 
>Ridpath recently published results of a color study, so I have CC'ed ER as 
>well.  Refer to the techniques for Checkpoint 2.2 in the 26 April 2000 
>working draft of AERT [1].
>
>Since there do not appear to be any objections to my proposed edit of the 
>CSS techniques module, I will make the appropriate changes.
>
>--wendy
>
>[1] http://www.w3.org/TR/AERT#color-contrast
>
>
>>On Thu, 8 Jun 2000, Wendy A Chisholm wrote:
>>
>>   I have two questions in relation to this issue:
>>   1. will user agents automatically make adjustments for background or
>>   foreground color if the author specifies a good combination but the user
>>   only specifies one or the other (foreground or background but not
>>   both)?  It is my experience that user agents do not.
>>
>>   2. I intend to include this in the techniques document, but would like a
>>   rationale.  It seems that the rationale is good design rather than an
>>   accessibility issue since the answer to the first question seems to be 
>> "no."
>>
>>   If there is no disagreement, I propose editing section 5 (Colors) of the
>>   CSS techniques module to read:
>>   <blockquote>
>>   Use these CSS properties to specify colors:
>>   'color', for foreground text color.
>>   'background-color', for background colors.
>>   'border-color', 'outline-color' for border colors.
>>   For link colors, refer to the :link, :visited, and :active
pseudo-classes.
>>

>>   Note that when a background color is specified, specify a high-contrast
>>   foreground color and vice-versa.
>>
>>   Ensure that information is not conveyed through color alone. For example,
>>   when asking for input from users, do not write "Please select an item
from
>>   those listed in green." Instead, ensure that information is available
>>   through other style effects (e.g., a font effect) and through context
>>   (e.g,. comprehensive text links).
>>   For instance, in this document, examples are styled by default (through
>>   style sheets) as follows:
>>   They are surrounded by a border.
>>   They use a different background color and also specify a high-contrast
>>   foreground color.
>>   They begin with the word "Example" (or "Deprecated Example".
>>   They also end with the phrase "End example", but that phrase is hidden by
>>   default with 'display: none'. For user agents that don't support style
>>   sheets or when style sheets are turned off, this text helps delineate the
>>   end of an example for readers who may not be able to see the border
around
>>   the example.
>>   </blockquote>
>>   --wendy
>>
>>   At 12:59 AM 6/7/00 , Wendy A Chisholm wrote:
>>   > From the issues list:
>>   >
>>   ><blockquote>
>>   >Issue raised by: Philip Newton - 7 May 1999
>>   >Issue:
>>   >If the author specifies a background color, they should also specify the
>>   >foreground color (and vice versa), otherwise if the user has selected a
>>   >particular foreground color that does not contrast well with the
author's
>>   >background color, the page will be unreadable.
>>   >
>>   >Proposed Resolution
>>   >While the user should be able to adjust preferences on the user
agent, it
>>   >is good design. Therefore, it seems to make sense to discuss in 
>> techniques doc.
>>   ></blockquote>
>>   >
>>   >Even if the author selects both a background and text color, if the user
>>   >selects a foreground color that does not contrast well with the author's
>>   >background color then what can you do?  If the user only selects one 
>> color
>>   >but the author has selected both foreground and background, the user 
>> agent
>>   >will not automatically use colors that contrast well, will it?
>>   >
>>   >I agree this is good practice but I am not sure that this increases
>>   >accessibility.
>>   >
>>   >Thoughts?  Do people have experiences that support the proposal?  Does
>>   >someone have a good test page for this?
>>   >--wendy
>>   >--
>>   >wendy a chisholm
>>   >world wide web consortium
>>   >web accessibility initiative
>>   >madison, wi usa
>>   >tel: +1 608 663 6346
>>   >/--
>>
>>   --
>>   wendy a chisholm
>>   world wide web consortium
>>   web accessibility initiative
>>   madison, wi usa
>>   tel: +1 608 663 6346
>>   /--
>>
>>
>>--
>>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134
136
>>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
>>Postal: GPO Box 2476V, Melbourne 3001,  Australia
>
>--
>wendy a chisholm

>world wide web consortium
>web accessibility initiative
>madison, wi usa
>tel: +1 608 663 6346
>/--
>

Received on Tuesday, 13 June 2000 23:11:41 UTC