Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

Dear Bim Egan,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.


Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: Contradiction in Understanding SC 1.4.8
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Dec/0055.html
(Issue ID: 2376)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

There's an apparent contradiction within Understanding 1.4.8:

http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/visual-audio-
contrast-visual-presentation.html

In the Intent of this Success Criterion

"People with some cognitive, language and learning disabilities and some
low vision users cannot perceive the text and/or lose their reading
place if the text is presented in a manner that is difficult for them to
read. "

and again under benefits:

Specific Benefits of Success Criterion 1.4.7: (sic)

This Success Criterion helps low vision users by letting them see text
without distracting presentational features. It lets them configure text
in ways that will be easier for them to see by letting them control the
color and size of blocks of text.

....

People with some cognitive disabilities can read text better when they
select their own foreground and background color combinations.

All of which appears to indicate that users should be allowed to define
foreground and background colors in their browsers.

However, this isn't reflected in the techniques, where, the first bullet
point seems to recommend specifying background and text colours.

Sufficient Techniques
1. Techniques to ensure foreground and background colors can be selected
by the user


* Specifying foreground and background colors in CSS (future link) OR

* Providing a color selection tool that allows a pastel background
(future link) OR

* Providing a multi color selection tool on the page for foreground and
background colors (JavaScript, Future Link) OR

* Using a technology that has commonly-available user agents that can
change the foreground and background of blocks of text (General, future
link)


If authors DO specify all foreground and background colors, it is
virtually impossible for users to select their preferred, or required,
choice, without also losing visual clues to menu bars etc.  Colour is an
important aid to recognising menu content when reading is difficult.

Shouldn't the first sufficient technique ask authors to refrain from
specifying inessential foreground and background  colors for substantial
blocks of text?   After that, the current list  could continue, with a
slight amendment to the present first bullet:
* Any specified foreground and background colors are in CSS, not HTML
(future link) OR


I do hope I've made this clear, but do reply if there are any questions.
I'd be delighted to create a page that demonstrates the advantages of
not specifying either background or foreground, if this would help.

---------------------------------------------
Response from Working Group:
---------------------------------------------

If we understand you correctly, you are saying that the current list
could be fixed if we changed the first bullet to read, "Any specified
foreground and background colors are in CSS, not HTML."

We agree that it is important not to specify some but not all of the
colors. We have taken your advice with a couple of edits. First, all
of the techniques have to be in a "...ing" form. Second, since user
agents or users' style sheets can override colors specified in CSS or
HTML, we did not include ", not HTML."

We have changed this technique into "Specifying all foreground and
background color attributes of any given element in CSS"

We have also added an existing technique, G148, and an existing
failure, F24, to this success criterion.

Please note that sometimes techniques are retitled when they are
written. If you are interested in helping to write up this technique,
it would be wonderful. The link for submitting techniques is
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/.

We also are very interested in your examples.

Received on Tuesday, 11 March 2008 00:18:58 UTC