- From: Michael Cooper <cooper@w3.org>
- Date: Wed, 25 Oct 2006 16:20:04 -0400
- To: List WAI GL <w3c-wai-gl@w3.org>
- Message-ID: <453FC6F4.6010406@w3.org>
Basic issues: Why is color treated differently from other variations
(redundant visual presentation vs. programmatically determined
variation); what is value of programmatically determining the variation
if you don't know what it means
* 1.3.2 (color alone) is not sufficiently disambiguated from 1.3.4
(variations in presentations in text).
* What's important to be programmatically determined is the meaning
implied by the variation in presentation, not the variation
itself. This could be accomplished with ARIA roles.
Counter-argument raised in WG: sighted users infer that meaning
from the presentation, and it's fair to expect non-graphical users
to do the same.
* Why color at level 1 and other variations at level 2?
* Is color a variation in presentation under 1.3.4?
* Underlines on links is an important visual cue to their "linkness"
and removing should be a violation of 1.3.2. However, that's not
strictly a color issue, and it's easy to think of examples where
underlines on links really interferes with design.
* Requiring redundant visual presentation of color intrudes into UI
domain, and won't accomplish our needs, need simply alternate
means of getting at info conveyed by color
* What is benefit of making variations in presentation
programmatically determinable?
*Comment LC-558*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Bruce Bailey <bruce.bailey@ed.gov> *Affiliation:* DoED/OCIO
*Comment Type:* substantive
*Location:* content-structure-separation-emphasis
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-emphasis>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
1.3.2 (color alone) is not sufficiently disambiguated from 1.3.4
(variations in presentations in text). Two of four examples, and only
Common Failure, in UNDERSTANDING should be associated with 1.3.4. The
implication is that 1.3.4 should be Level 1.
Proposed Change:
Promote 1.3.4 to Level 1. It may then be possible to demote 1.3.2 to
Level 2 or 3.
I am also commenting on UNDERSTANDING and TECHNIQUES but with the
assumption that 1.3.2 and 1.3.4 are correct as-is.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
Relates to LC-559 and LC-560
Discussed at Team C Call 30 May, 2006
http://www.w3.org/WAI/GL/2006/05/30-wcag-teamc-minutes#item03
See WCAG 2.0 History of Changes for 24 February, 2006, working draft
http://www.w3.org/WAI/GL/WCAG20/change-history.html
Comments clarified via a phone conversation with Bruce. He meant
"techniques", not "examples". Also, he said to disregard his comment
about the common failure.
The comments about two of the 1.3.2 techniques really belonging to 1.3.4
are duplicated in issues 559, and 560 and so are addressed there. The
proposal for this issue deals only with Bruce's suggestion to move SC
1.3.2 to Level 2 and 1.3.4 to Level 1.
Additional research and discussion posted to
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/att-0027/00-part.
<proposal>
[REJECT]
1.3.2 was previously a Level 2 Success Criteria. The Working Group
decided between January 17th and February 24th, 2006, to elevate it to
Level 1 because of the desire to require a visual differentiator for
color blind users. If 1.3.2 is moved to Level 2 and 1.3.4 is moved to
Level 1, then all that would be required is for the color change to be
programmatically determinable.
</proposal>
01 June 2006
resolution: 558 - refer it for further work
http://www.w3.org/WAI/GL/2006/06/01-wai-wcag-minutes.html
--
Discussed on the 22 June 2006 teleconference
Resolution: Put issue LC-558 on hold for possible addtional public
comments.
Note: refer to survey comments for 15 and 22 June from Team C
http://www.w3.org/WAI/GL/2006/06/22-wai-wcag-minutes.html
*Resolution Working Notes - Unapproved:*
[PARTIAL]
1.3.2 was previously a Level 2 Success Criteria. The Working Group
decided between January 17th and February 24th, 2006, to elevate it to
Level 1 because of the desire to require a visual differentiator for
color blind users. If 1.3.2 is moved to Level 2 and 1.3.4 is moved to
Level 1, then all that would be required is for the color change to be
programmatically determinable.
Note that in HTML and CSS color change is already programmatically
determinable, so nothing would have been added. Additionally, suggestion
to provide information in text does not meet principle of Level 1 that
it not affect visual design.
To clarify situation, we will create a new sufficient technique for
1.3.2 situation A: "Using semantic markup whenever color cues are used"
(and reference H49). The technique is available at:
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0033.html
*Related Issues:*
*Assigned To:* Becky Gibson
*Last Edited:* 2006-10-23 20:16:21
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/558>*
------------------------------------------------------------------------
*Comment LC-583*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Jason White
<jasonw@ariel.its.unimelb.edu.au> *Affiliation:* none
*Comment Type:* substantive
*Location:* content-structure-separation-emphasis
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-emphasis>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
If it is sufficient that the change in presentation of text can be
programmatically determined, then most changes in presentation (other,
perhaps, than in bitmapped images) will meet this criterion. The user
agent,
after all, requires this information in order to render the change.
However, programmatic determination of the change in presentation is not
sufficient to meet the requirements of user agents and assistive
technologies
providing presentations in other modalities (or in the same modality with
different stylistic requirements according to the needs of the user with a
disability). How is the user agent supposed to map the change in
presentation
to a corresponding change, whether in text or in presentation, in its
generated rendering, if the purpose or meaning of the variation in
presentation cannot be programmatically determined? In the worst case, it
could simply \"announce\" the change, e.g., \"voice pitch flat\" or
\"font size
14pt\" and leave the user to try to work out the significance, if any,
of this;
but a better solution is to use the capabilities of the technology to
convey
the meaning or significance of the change, while also allowing \"merely
decorative\" changes having no meaningful purpose to be ignored.
This shortcoming of the current criterion is addressed in the proposal
below.
Proposed Change:
\"The meaning or purpose of the change in presentation of text can be
programmatically determined\". Alternatively, just \"purpose\" could be
used in
place of \"meaning or purpose\" in the above. Alternatively, keep this
criterion
as is and add a more stringent requirement at level 2 or level 3.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Christophe Strobbe
*Last Edited:* 2006-10-23 20:16:28
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/583>*
------------------------------------------------------------------------
*Comment LC-635*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Lisa Seeman <lisa@ubaccess.com> *Affiliation:* Invited
expert at W3C, UB access
*Comment Type:* substantive
*Location:* content-structure-separation-without-color
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-without-color> (Level
1 Success Criteria for Guideline 1.3)
*Comment:*
Comment (including rationale for proposed change):
With new technology such as roles within the WAI, you can assign the
role of the object in a programmatically understandable way. Also you
can use RDF, xfroms etc to similar affect.
Proposed Change:
1.3.2 Any information that is conveyed by color can be programmatically
determined or is also visually evident without color
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
While there is support in Xforms and with Dynamic Web Content
Accessibility,k I don't think these are well enough supported to add
"programmatically determined" back into the Success criteria. As we have
discussed in the past, the style information to assign a color can be
programmatically determined. In discussions to this point, the WG does
not feel that programmatically determined is sufficient since it is not
well supported by assistive technology. I have drafted a technique about
using the required attribute that could be tweaked to fit this SC about
color. Currently the technique uses an asterisk and required=true to
mark a required field - it could be modified to use color and
required=true to better fit this SC.
I haven't drafted a response because we need to work out the
"programmatically determined" issue with this SC. This belongs to a
group of comments about color variations etc.
[Becky] I have thought about this more and I think that we actually CAN
change the SC. It is not stating the the COLOR can be programmatically
determined but that the INFORMATION is programmatically determined. So,
just knowing that an item is a particular color does not give you the
information that it is required .
Reword SC 1.3.2 as
Any information that is conveyed by color is visually evident without
color or the information can be programmatically determined.
Add a failure. Failure due to conveying information via text color
alone. The failure would be a form that has the instructions, "Required
fields are labeled with red text". With the explanation that even though
a user agent or assistive technology can programmatically determine that
text label for a field is in a particular color, this SC requires that
the user be able to obtain the information about the field - that it is
required.
I also think that this would prevent the recently added sufficient
technique that you can use color AND text variation. That should also fail.
Once Dynamic Web Content Accessibility is approved as a spec - the
recently approved advisory technique for 1.3.1 about using the required
property could become sufficient without the addition of the asterisk
character.
Although this is still a bit tricky - I don't know how we expect a user
agent to indicate that a field is required other than via a visual
means? I guess it depends upon how forward looking we want to be?
Currenlty the only way to programmtically determine that a field is
required (as the most common example of information conveyed by text
color) is via Dynamic Web content Accessibility.
*Resolution Working Notes - Unapproved:*
*Related Issues:*
558 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=558>
*Assigned To:* Becky Gibson
*Last Edited:* 2006-10-23 20:16:32
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/635>*
------------------------------------------------------------------------
*Comment LC-636*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Lisa Seeman <lisa@ubaccess.com> *Affiliation:* Invited
expert at W3C, UB access
*Comment Type:* substantive
*Location:* content-structure-separation-emphasis
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-emphasis> (Level
3 Success Criteria for Guideline 1.3)
*Comment:*
Comment (including rationale for any proposed change):
the information for the user is important not the change in presentation...
Proposed Change:
Information that is conveyed by variations in presentation of text is
also conveyed in text, or the informations can be programmatically
determined.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
see teamc thread beginning here:
http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jun/0059.html
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Becky Gibson
*Last Edited:* 2006-10-23 20:16:35
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/636>*
------------------------------------------------------------------------
*Comment LC-715*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Wayne Dick <wed@csulb.edu> *Affiliation:* CSU Long Beach
*Comment Type:* substantive
*Location:*
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Rationale: Often the \"variation in text\" can be determined
programmatically but the information this variation conveys cannot.
Proposed Change:
Change: Include the bracketed words...
1.3.4 Information that is conveyed by variations in presentation of text
is also conveyed in text, or [the information conveyed by] the
variations in presentation of text can be programmatically determined.
[How to meet 1.3.4]
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
MichaelC: I would like to take this reviewer's suggestions but think
there may be specific reasons this is worded as is. But this SC has
issues that have been put on hold and this should join that batch and
get dealt with with them. Note there are several votes along similar
lines to this proposal.
Related comments: LC-558, LC-583, LC-636, LC-1284, LC-1362 (removed?)
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-23 20:16:39
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/715>*
------------------------------------------------------------------------
*Comment LC-742*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Eric Hansen <ehansen@ets.org> *Affiliation:*
Educational Testing Service
*Comment Type:* substantive
*Location:* content-structure-separation-without-color
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-without-color>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
1.3.2 Any information that is conveyed by color is also visually evident
without color.
Presumably it could be evident by shape, size, location, etc...... This
seems problematic, since what is visually evident depends so heavily on
the person. For some, nothing is visually evident....!
Proposed Change:
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
[reject] The requirement to be visually evident is intended to benefit
those who can perceive and interpret the visual cues. However, for those
who cannot perceive them, SC 1.3.1
(#content-structure-separation-programmatic) separately requires that
the information be programatically determined. These two SC are intended
to be complementary to each other.
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-23 20:16:42
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/742>*
------------------------------------------------------------------------
*Comment LC-863*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Joe Clark <joeclark@joeclark.org>
*Comment Type:* substantive
*Location:* content-structure-separation-emphasis
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-emphasis>
*Comment:*
From
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
WCAG 2 is nearly consistent in pretending that Web standards do not
exist (with one curious exception that I'll get to shortly). Some
teenagers have greater understanding of valid, semantic markup than the
Working Group does, as evinced in passages like these:
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.
Now, what does ""presentation"" mean? Really?
Doesn't the requirement to convey the information in text make it
possible to write instructions for an online form as follows?
* Fields marked in red are required.
* Fields marked in green are optional but recommended.
I have just ""conveyed"" the colour differences. (It so happens that the
colours are exactly the rare ones that are confusable to colourblind
people.)
If I am using markup to vary presentation of text, as one typically will
(how else do you do it if you aren't using a picture of text?), how is
that markup ever not programmatically determinable? The browser had to
read it to vary the presentation in the first place. All the usual
elements, like em, strong, b, i, and u, are understandable by a machine.
So is CSS, even at the simple level used in this document as a
demonstration (span class=""red"" or =""green""). More complex CSS
selectors, like :last-child, are also programmatically determinable.
In essence, for any author using markup, even lousy presentational
markup, how is it possible to flunk this criterion?
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
David MacDonald takes a shot at a response:
[Reject]
Respond with:
Required fields that are distinguishable by colour only would fall under
guideline 1.3.2 "Any information that is conveyed by color is also
visually evident without color."
The definition of "programmatically determined" requires that the
information must not only be determinable, but that it must be
determinable in a "user-agent-supported manner."
The definition of "User agent supported" has been updated re: Comment
1508 to the following:
<new_definition>
user-agent-supported
implemented by user agents including assistive technologies
Note: One of the factors that should be considered before adding a
technology to a baseline is the availability of affordable user agents
and assistive technologies which support the technology.</new_definition>
The definition makes it clear that programmatic determination includes
assistive technologies. If it is not determinable by current AT then it
would fail.
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-20 14:55:05
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/863>*
------------------------------------------------------------------------
*Comment LC-1080*
*Sort Terms:* color/variations/programmatically
*Document:* Understanding WCAG 2.0
*Submitter:* Gian Sampson-Wild <gian@tkh.com.au>
*Comment Type:* substantive
*Location:* content-structure-separation-without-color
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/#content-structure-separation-without-color> (Common
Failures)
*Comment:*
Add failure: Add a failure where the default underline is removed from
linked text - therefore links are only differentiated from normal text
through colour alone
Proposed Change:
I am happy to create this failure
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
I think the failure should be more generic than removing underline,
perhaps: Failure due to distinguishing links by color alone
This situation is covered by other techniques but it may be worth an
HTML specific failure about links.
Becky's proposal was:
{accept}
Thank you for the suggestion. We have created a failure technique
titled, @@see accepted title below.
@@ create failure technique titled, "Failure due to distinguishing links
by color alone."
Discussed at Sept. 12 team c meeting and concerns were raised:
removing underlines from links (with no other visual modification) is
technically a failure, but leaving underlines on links can be a real
mess on some sites
We should discuss in context of other issues in 1.3.2
David Adds:
Links underlines should not be required in sections that are clearly
identifiable as navigation areas. Examples would be a navigation bar,
site map table of contents ect...
I think the distinguishing factor should be that underlines are required
when there is non link text either before or after the link such as in a
sentence or paragraph.
*Resolution Working Notes - Unapproved:*
David takes a shot at a response:
[partial accept]
@@add a failure
"Failure due to distinguishing a link by color alone when the link is
not part of a list of links"
Or (more understandable)
"Failure due to removing a link underline when the link is not part of a
list of links"
@@The intent would read:
The intent of this failure is to ensure that people who cannot perceive
color can identify links. Links underlines are required in sections that
not clearly identifiable as navigation areas. Examples of a navigation
area are a site map, table of contents, navagation bar, or other group
of links. If the link text is preceded or followed with non link text,
as when part of a sentence or paragraph, then it would be a failure to
removed the underline."
Respond with:
Thank you. We have added a failure. "Failure due to removing a link
underline when the link is not part of a list of links"
The committee agrees that underlined links are important when they are
part of a sentence or paragraph or other area where they could be
mistaken as non-linked text.
However, there may be good reasons to remove underlining when the link
is part of a navigation bar, site map, table of contents or other
navigation structure that contains many links together. In cases where
it is clear that all text is linked, the removal of the underlines would
make less clutter and therefore could help some people with cognitive
disabilities. We feel therefore that we should allow this exception.
*Related Issues:*
*Assigned To:* Becky Gibson
*Last Edited:* 2006-10-17 13:36:38
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/understandingwcag20/1080>*
------------------------------------------------------------------------
*Comment LC-1083*
*Sort Terms:* level-change color/variations/programmatically
*Document:* Understanding WCAG 2.0
*Submitter:* Gian Sampson-Wild <gian@tkh.com.au>
*Comment Type:* general comment
*Location:* content-structure-separation-understanding
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/#content-structure-separation-understanding>
*Comment:*
Move to Level 1: From what I understand, this is the equivalent of
making sure information is not provided via colour alone, so why is it
at Level 2?
Proposed Change:
Move 1.3.5 to Level 1
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-16 16:03:34
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/understandingwcag20/1083>*
------------------------------------------------------------------------
*Comment LC-1157*
*Sort Terms:* Color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Greg Lowney
<gcl-0039@access-research.org> *Affiliation:* Lowney Access
Research, LLC
*Comment Type:* substantive
*Location:* content-structure-separation-without-color
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-without-color> (Description)
*Comment:*
The phrase "visually evident without color" could be misinterpreted as
meaning "visually evident, and without color". Suggest rephrasing to be
less ambiguous.
Proposed Change:
Change "visually evident without color" to read "visually evident even
if any color cannot be perceived".
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
[accept]
@@ Change in 1.3.2. "visually evident without color" to read "visually
evident even if color cannot be perceived".
Respond with: Thank you, your suggestion has been accepted. SC 1.3.2 now
reads {@@wording}.
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-20 14:55:45
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1157>*
------------------------------------------------------------------------
*Comment LC-1202*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Al Gilman <Alfred.S.Gilman@IEEE.org>
*Comment Type:* substantive
*Location:* content-structure-separation-without-color
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-without-color>
*Comment:*
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.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-23 20:17:07
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1202>*
------------------------------------------------------------------------
*Comment LC-1284*
*Sort Terms:* color/variations/programmatically
*Document:* WCAG 2.0 Guidelines
*Submitter:* Andrew Arch
<andrew.arch@visionaustralia.org> *Affiliation:* Vision Australia
*Comment Type:* substantive
*Location:* content-structure-separation-emphasis
<http://www.w3.org/TR/WCAG20/complete.html#content-structure-separation-emphasis>
*Comment:*
Comment: "variations in presentation of text can be programmatically
determined." - yes, a graphical browser can display italicised text, but
not much, if any, AT can determine its existance.
Proposed Change:
reconsider/clarify/strengthen this SC, or drop the last part.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-23 20:17:11
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1284>*
Received on Wednesday, 25 October 2006 20:19:01 UTC