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

Re: Your comments on WCAG 2.0 Public Working Draft of May, 2007

From: Shawn Henry <shawn@w3.org>
Date: Thu, 15 Nov 2007 16:41:57 -0600
Message-ID: <473CCB35.4020109@w3.org>
To: public-comments-wcag20@w3.org

Hi WCAG WG folks,

Thanks for considering my comments, and for all of your work on WCAG 2.0!

My replies are below preceded with Shawn:

Comment 1: LC-992, LC-1000: organizational comments on guidelines
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0326.html
(Issue ID: 2181)
Original Comment:


The addition of short handles on the success criteria and principles
is excellent. I still recommend them for the guidelines as well, for
the same reasons stated previously.


My proposed change had three points. The first was: "Leave the
Principles as they are in /TR/WCAG20. Remove the first numbering from
all guidelines and success criteria..." I'm not sure I agree with your
response to that point; however, I am quite willing to accept the
decision of the Working Group, especially since you added short
handles that make referencing the success criteria in informal
communication so much easier and reducing the need to use the numbers
for common reference.

I don't see a response to my other two points:
* Add the Principles into "Understanding". - I see that there is now a
"Understanding the Four Principles of Accessibility" section in the
Understanding doc, and I don't think it make sense to add them as
headings throughout the doc. Therefore, I think this comment is
* Consider including the Principles in the Quick Ref and Checklist. -
I think it would probably be best to have the Principles in the Quick
Reference. However, I haven't done enough work with users yet to have
a good idea of the issues for and against having the Principles there.
In order to simplify overall comment processing (for me and you), I
will open a new comment on the Quick Reference, and you can close this

Response from Working Group:

We have now created Handles for the Guidelines as well.

Shawn: Great!

We have shortened the introduction considerably and moved the
principles discussion to the Understanding Document.  We have also
edited the principles in response to a wide range of comments.

Shawn: Great!

We did not add the principles to the Quick Reference because, on
investigation, we found it added more complexity to the document than
we want to have.

Shawn: EOWG discussed this and generally agree that while it would be nice to have the Principles in the Quick Reference (some people felt very strongly about this and others not as much), it is not worth adding another heading level. A compromise suggestion we came up with is adding the Principles in the table of contents only (not linked of course).

Comment 2: 1.4.3 and 1.4.5 missing "background" ? only text ?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0032.html
(Issue ID: 2318)
Original Comment:

Current wording: "Text (and images of text) have a contrast ratio of
at least..." It seems you need to say that the text has a contract
ratio with it's background, e.g., previous wording "Text or diagrams,
and their background, have a luminosity contrast ratio of at least

Also, does this really only cover text? Are other things -- such as
data in a graph -- covered elsewhere?

Response from Working Group:

You will find the word 'backgound' in the definition of "contrast
ratio".  It is commonly understood that requiring text to have
contrast means contrast with what is immediately behind it. We removed
the phrase 'and their background', since this is often a relative
concept in technologies like HTML/CSS that can scroll or reflow and
have partial opacity. In general what is 'background' is not knowable
until the final rendering, and the original clause implied a level of
fixity which was not appropriate. It is therefore better handled in
the definitions where it talks about foreground and background and it
is clearer.

We are only applying this to text because when we tried applying it to
other things like graphs and charts we ended up with numerous
exceptions and problems.      In the end we decided that the most
severe problem was reading running text when the contrast is very low.

Shawn: I am uncomfortable with not having contrast for things such as data in a graph or chart included in the guidelines. However, I don't want to hold up moving WCAG 2.0 forward over it. Therefore, I am satisfied with the response. Would you consider addressing this in Understanding; that is, clarifying somewhere that there should be sufficient colour contrast on things like graphs and charts, even though it is not a requirement.

  Also, data in a graph would need to be described in a long
description - and can be viewed under magnification.

Shawn: This doesn't help for many people who need significant colour contrast. It is common for people with diminishing vision due to ageing to need good colour contrast, and not have a user agent or AT that provides access to the long description.

Comment 3: Guideline 1.1 wording
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0033.html
(Issue ID: 2319)
Original Comment:

Here is a note related to a previous comment that suggests changing
"Guideline 1.1 Provide text alternatives for any non-text content so
that it can be changed into other forms people need such as large
print, braille, speech, symbols or simpler language"
"Guideline 1.1  Provide text alternatives for all non-text content."

In a usability test of the Quick Reference the participant was slowed
down and bothered by the extra wording. Even though he is not an
accessibility specialist, he already knows about alt text (as will a
large percent of the people who will be using WCAG 2.0). He had a few
things to say about it, including suggesting a simple example under
each one. He concluded with: "It should be 'Guideline 1.1: Provide
text alternatives. full stop. Then the rest is underneath it. That way
I can skip it if I already grok it."

I agree with keeping the guideline text short and succinct, and
putting the other information outside of the guideline text itself. (I
envision having an option on the Quick Reference to show brief
explanations and examples... but that's another thing...)

Response from Working Group:

That is what it said before we added the extra language to make it
easier to understand for people new to the guidelines and for
policymakers etc.  We were concerned that adding the information as a
note would cause it to be lost as the guidelines were copied, made
into lists etc.

Shawn: This is a judgment call between making the guideline text easy to skim and understand visually and cognitively for those with some basic knowledge, vs. making the guidelines text more detailed for those new to accessibility. I prefer the first. However, the addition of the handle "Text Alternatives" facilitates skimming an d therefore, I am satisfied with this response.

Received on Thursday, 15 November 2007 22:43:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:09 UTC