W3C home > Mailing lists > Public > public-wcag-teama@w3.org > May 2006

Re: 1.3.2 (don't only use color)

From: Bailey, Bruce <Bruce.Bailey@ed.gov>
Date: Thu, 25 May 2006 15:26:04 -0400
Message-ID: <CCDBDCBFA650F74AA88830D4BACDBAB50B2D4D85@wdcrobe2m02.ed.gov>
To: <public-wcag-teama@w3.org>
Cc: <w3c-wai-gl@w3.org>

FYI, this is not on today's agenda and not covered in this week's survey.

My concerns are also reflected via public comment as (currently open) issues 558, 559, and 560.

As much as anything, I am posting here so I have a URL to reference when this comes up in a survey.

If it is the deliberate intention that SC 1.3.2 address *only* color blindness, someone please clue me in.  It may be the case that I need to be disavowed of the notion that WCAG 2.0 meant to close a loop hole left by WCAG 1.0 P1 Checkpoint 2.1.  My earlier post (below), three submissions above, and this note all follow from my understanding that this is a deficit that warrants being addressed.

Success Criteria 1.3.2 as it stands currently:

[A] 1.3.2 Any information that is conveyed by color is also visually  
evident without color. (Level 1)

Part of the explanation leads me to understand that the intent is,  
indeed, to address problems like:  "the labels for required fields  
are in red."  I infer this from the text-oriented examples of  
Situation A from the techniques document at URL:

http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/Overview.html#content-structure-separation-without-color

aka http://tinyurl.com/z52aj

<blockquote>
Situation A: If the color of particular words is used to indicate  
information.
1. Ensuring that color encoded information is also available in text.
2. Including a text cue whenever color cues are used.
</blockquote>

The defect (WCAG 1.0 P1 Checkpoint 2.1 has the same problem) follows  
from the success criteria requiring a visual alternative to a barrier  
that arises from visually-oriented prejudices.  Please correct me if  
I am wrong, but I understand that the intent behind 1.3.2 is to  
address generalized low vision and blindness and not just confuse- 
able colors and monochromacy.

I can think of two relatively minor edits to 1.3.2 that superficially  
addresses the issue:

[B] 1.3.2 Any information that is conveyed by non-text content using  
color is also visually evident without color. (Level 1)

[C] 1.3.2 Any information that is conveyed by color is also conveyed  
in text. (Level 1)

The problem with [B] is that textual information conveyed by color is  
not addressed, except by 1.3.4 (information that is conveyed by  
variations in presentation of text) which is Level 2.  Is this okay?

The problem with [C] is that now the image-oriented examples of  
Situation B (same URL as above) is no longer address at all.  Is that  
okay?

<blockquote>
Situation B: If color is used within an image to convey information.
1. Using color and pattern (for example, colors on bar/pie charts  
with lines or texture fills).
2. Ensuring that color encoded information is also available in text.
</blockquote>

The temptation might be to re-write 1.3.2 so that it is in the style  
of 1.3.4.  That would give us:

[D] 1.3.2 Information that is conveyed by color is also conveyed in  
text, or the color can be programmatically determined. (Level 1)

[E] 1.3.4 Information that is conveyed by variations in presentation  
of text is also conveyed in text, or the variations in presentation  
of text can be programmatically determined. (Level 2, as is)

The problem with both [D] (with regards to text) and [E] is that we  
already have this capability with screen readers and in the vast  
preponderance of situations, it is not useful.  The screen reader can  
usually query the OS to announce the current font color and style.   
The difficulty is knowing when to issue such an instruction, but also  
to mentally correlate the presentational effects with meaning.  Font  
changes can be set to announce automatically, but in actual practice  
that results in so much useless chatter from the screen reader that  
few end-users routinely use this setting.

So, how to fix this?

I believe that the correct approach is go with [C] *and* [B] (or even  
keep 1.3.2 as-is [A]) but lower [B] (or [A]) to Level 2 or Level 3.

Thanks for your time and consideration!


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl@w3.org] On Behalf Of Bailey, Bruce
Sent: Monday, May 15, 2006 2:05 PM
To: w3c-wai-gl@w3.org
Subject: 1.3.2 (don't only use color)

Apologies for not picking up on this sooner.  If the rational for the change is available, I could much appreciate a URL.  I do not see this discussed in the Wiki.

The current (27 April 06) version:
1.3.2 Any information that is conveyed by color is also visually evident without color.

Actually closely follows WCAG 1.0 (2.1: Ensure that all information conveyed with color is also available without color, for example from context or markup.) but to a fault, as it has the same flaws.

Consider using bold or italics to indicate required fields on a form.  This satisfies both the success criteria / checkpoint, even though such a technique is really *not* sufficient for someone using a screen reader.

The previous version was a little better:

1.3.2 When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors. 

Both the (current) 1.3.2 and WCAG1 GL 2.1 suffer from the same problem that the How To Meet examples get to the intent, but not the literal wording of the standard.

<blockquote>
Ensuring that color encoded information is also available in text.
Including a text cue whenever color cues are used.
</blockquote>

The identified Common Failure also gets at the intent, but not the literal wording of the standard:

<blockquote>
Failure of SC 1.3.2 due to having a text alternative that does not include information that is conveyed by color in the image.
</blockquote>

Now, if something like font-based effects (besides color) is used to convey information (like required fields) we can get to that from L1 SC 1.3.1, Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.  But that is a lot of work to notice which form labels are bolded (for example) and really the same level of effort as is needed to reveal which form labels are in red.

Is color really that distinct from other superficial visual effects that it warrants its own success criteria?

Is using a font-change (but not a color change) to provide information caught by anything other than SC 1.3.1?

Should 1.3.2 be rolled into 1.3.1?  (Given the timing, I am sure the answer is no.  But I am troubled by an SC that is meant to help people with visual deficits requiring a visual, not a textual, alternative.)
Received on Thursday, 25 May 2006 19:26:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:40 GMT