W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > June 2007

disagree LC-1202 (with how to salvage...) [was: Re: Your comments on WCAG 2.0 Last Call ...]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 22 Jun 2007 20:37:01 -0400
Message-Id: <p06110412c2a219a42dff@[]>
To: public-comments-WCAG20@w3.org

At 4:27 PM -0700 17 05 2007, Loretta Guarino Reid wrote:
>Comment 33:
>Source: http://www.w3.org/mid/p06110403c0bf326d6713@[]
>(Issue ID: LC-1202)
>Requiring that the other way of showing the color-signaled information
>is visual is a UI requirement.  It is not a content requirement.
>This requirement is inappropriate for a claim that includes SALT in
>its baseline such that the default presentation would speak the
>information as well as show it with color.
>Compare with UAAG 2.3.  Sometimes you should not try to replicate the
>richness of the color coding in other, more limited property spaces,
>but rather signal that there is further information and expand on the
>further information on user interactive request.
>Compare also to the 'minimized' treatment of notes in a DAISY player.
>Here the presence of a note is evident, the content of the note is
>available but on an 'ask for' basis.
>24 bits per pixel of color-coded information is just too much
>information to assume that other visual effects can capture it all.
>Proposed Change:
>User Interface requirement:
>strike the word 'visually' to leave "is also evident, or is available
>and the availability of more information is evident"
>Content requirement:
>The default prsentation afforded without user intervention satisfies
>the above requirement.
>[alternate language:  .. is visually evident ... in the
>author-designed visual presentation of the content]
>Content requirement:
>The connotations of color and other presentation-properties constitute
>non-text information and must (per 1.1.1) be afforded text
>explanations that are associated with the items bearing these
>presentation effects (and connotations), associated by an association
>that can be programmatically determined.
>Response from Working Group:
>The group thinks that situations where the density of the color would
>affect the information in such a way that it is too subtle or
>complicated to be visually rendered in another way, are extremely

You are not thinking of all situations where information is conveyed
by color differences.

"Extremely rare" is false, and we just go through telling HTML WG
that they can't kill the 'headers' attribute because they think that
the cases where 'scope' is not enough are 'rare.'

What is sauce for the goose is sauce for the gander.

I believe that what you mean is not any "information conveyed
by color differences" as in all pseudocolor visualizations, but
rather "color-coded information" which could be explained in
the glossary as

color-coded information:

Information taking values in a small discrete set that is visually
cued by conventional colors in different areas on the canvas.

>UAAG 2.3 applies to conditional content, and is not equivalent to
>necessary information that a color blind person can't access.
>The DAISY player example of minimizing notes is a different issue
>because they are not equivalents to content. They are enhanced
>information, so it makes sense that people should take extra steps to
>access that information. The group does not think color blind people
>should be required to go elsewhere to get basic information in
>circumstances such as those covered in this success criteria. Color,
>as it applies to this success criteria, is often text based
>information, and therefore would not be covered under SC 1.1.1.

Yes, there are frequent uses of color to convey simple discrete
enumerated types of data that can be readily shown by small sets
of values of some other visual property.

But you need to state the applicability of this rule better. Limit
the 'then' clause to a 'where' that isolates the appropriate subset
of color-borne information. Your language at present still casts too
broad a net.


Received on Saturday, 23 June 2007 00:37:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:44 UTC