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

Dear Christophe,

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: H36: Using alt attributes on images used as submit buttons
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0082.html
(Issue ID: 2533)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

When we developed test case sc1.1.1_l1_240 [1], we discovered that
the test procedure defines no requirements for the alt text. The
description states: "This label indicates the button's function, but
does not attempt to describe the image." However, the test procedure
only checks for the presence of the alt attribute.

Proposal:

* Add a second step: "Check that the alt attribute indicates the
button's function."

* Update the expected results: "#1 and #2 are true".

(This comment was previously submitted at
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Sep/0003.html.)

[1] http://bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc1.1.1_l1_240

Christophe Strobbe

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

We have changed the test procedure as proposed.

----------------------------------------------------------
Comment 2: G14: Does example 2 fail the success criterion?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0083.html
(Issue ID: 2534)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

When we evaluated test case sc1.4.1_l1_011 [1] for technique G14, we
thought that the second example in that technique fails the success
criterion. The example describes the use of text alternatives on
colour icons (for coding the tracks in a conference). The text
alternative is not good enough (as the test procedure points out)
because that is conditional content; the SC requires that the
colour-coded information is "simultaneously visually evident". That
is not the case for alternative text.

So example 2 appears to fail both the test procedure and the success
criterion.

Proposal:

Remove example 2 (or modify it?).

[1] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc1.4.1_l1_011

Best regards,

Christophe Strobbe

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

Thank you. We had modified the Success Criterion but didn't catch the
example. We have removed the example.

----------------------------------------------------------
Comment 3: contrast algorithm for 1.4.3: Contrast (Minimum)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0084.html
(Issue ID: 2535)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Success criterion 1.4.3 relies on an algorithm
for relative luminance [1] that is different from
the algorithm in the draft for "Techniques For
Accessibility Evaluation And Repair Tools" [2].
Research in BenToWeb investigated four different
formulas for calculating colour contrast:

* WAI Accessibility Evaluation and Repair Tools
(Ridpath and Chisholm, 2000), brightness equations ("AERT/B"),

* WAI Accessibility Evaluation and Repair Tools
(Ridpath and Chisholm, 2000), colour contrast equations ("AERT/CC"),

* W. S. Thune (2003) [3] has provided a series of
equations, known as the Catman equations, using
linear, quadratic and cubic functions (Catman1, Catman2, Catman3),

* WCAG 2.0 – Working Draft 17 May 2007: contrast ratio definition (WCAG2).

AERT/B turned out to be closer to real user
experience (based on user testing) than the other
algorithms. User testing led to the
recommendation of a brightness difference of at least 66.8.

[1] http://www.w3.org/TR/WCAG20/#contrast-ratiodef

[2] http://www.w3.org/TR/AERT#color-contrast

[3] http://www.iastate.edu/~class.12003.engl.313/cps/contrast.html


Best regards,

Christophe Strobbe

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

All of the algorithms will look better for one sample vs another.
Since the old formula was non-linear, it is likely to be better for
some samples and not for others.   We tried to look at the study you
cite, but it appears to be a student project and it is no longer
available.  So, we cannot comment on it.

Some more specific notes on the new and the old algorithms.

The WCAG 2.0 contrast algorithm does not test for good color
combinations, just for those combinations with sufficient contrast
(based on brightness or relative luminance). The new WCAG 2.0
algorithm was chosen because it is much more consistent in its
results. For one thing the old algorithm was calculated in non-linear
color space while the new algorithm is calculated in in linear terms.
There is no way to correctly calculate contrast in non-linear space.
It will give you irregular results (good results in some areas of the
color space and bad results in others). The new WCAG 2.0 rule also is
based on luminance contrast alone - whereas the old measure included
color contrast as well. This causes the old algorithm to fail things
that have plenty of visual contrast for people with all types of color
limitation. For example some color combinations will fail the old tool
even though they are eminently readable and have a luminance contrast
of 15:1 or more (where 21:1 is pure black on white). Very dark
charcoal gray on yellow (contrast ratio of 16:1) would fail the old
algorithm. 100% green on black (same as old CRTs) (contrast ratio of
15:1) would also fail the old algorithm.

Having said all that, the new contrast ratio was chosen to be somewhat
less stringent than the old - in order to provide a larger color
palette for authors who are trying to meet the provision.

IN SUMMARY: The new algorithm is a better overall algorithm. However,
the values chosen for use with the new algorithm (5:1) do result in a
somewhat less strict level for some color combinations. This was done
to allow a somewhat less restricted number of colors when creating
pages that could meet the criterion. However, the new criterion is
more strict than the old in some areas, but it is much more consistent
in its results. For one thing, the old algorithm was calculated in
non-linear color space while the new algorithm is calculated in in
linear terms which better match vision.

----------------------------------------------------------
Comment 4: Language Subtags (Techniques H57 and H58)
Source: http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0085.html
(Issue ID: 2536)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Techniques H57 ("Using language attributes on the html element") and
H58 ("Using language attributes to identify changes in the human
language") are silent on language subtags. However, the BenToWeb
project found unexpected behaviour when language subtags were used.
At least one screen reader (JAWS 8.0, both with Internet Explorer 6
and Firefox 2) ignored the language markup and used its default
language for speech synthesis when a language subcode was used on the
'html' element.

We developed several test cases with language subcodes. With JAWS set
to American English, sc3.1.1_l1_006 [1] (American English),
sc3.1.1_l1_007 [2] (British English) and sc3.1.1_l1_008 [3] (language
code for British English) are read as American English; with JAWS set
to British English, sc3.1.1_l1_006, sc3.1.1_l1_007 and sc3.1.1_l1_008
are all read as British English. So it seems that language subcodes
can't be relied on by web developers.

[1] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_006
[2] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_007
[3] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_008

Best regards,

Christophe Strobbe

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

We have clarified the use of language subcodes by adding a note to the
description of these techniques, and adding a user agent note about
the JAWS behavior upon encountering lang tags that use subcodes.

----------------------------------------------------------
Comment 5: SC 3.1.3: Glossary without Links Should Fail?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0086.html
(Issue ID: 2537)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Test case sc3.1.3_l3_004 in the second version of the BenToWeb test
suite [1] contains text with jargon and the jargon is explained in a
glossary below the text. However, there are no links between the
occurrences of jargon in the text and the corresponding glossary
entries below the text. User testing did not convincingly show that
this is sufficient for users of a screenreader or magnification
software. So technique G62 (for Situation A) may need to specify
stricter requirements on how the glossary can be located.

[1] http://www.bentoweb.org/ts/XHTML1_TestSuite2/metadata/sc3.1.3_l3_004


Best regards,

Christophe Strobbe

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

Although a tight linking between the word and its meaning is desirable
and recommended, a glossary in the document is felt to be sufficient
to meet 3.1.3.


----------------------------------------------------------
Comment 6: SC 3.3.1: Providing client-side validation and adding error
text via the DOM (future technique )
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0087.html
(Issue ID: 2538)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Test case sc2.5.1_l1_025 in the second version of the BenToWeb test
suite [1] (for the April 2006 working draft) tried to implement this
technique but failed. The test file contains two mandatory text input
fields (first name, last name) that are already filled and set to
read-only. In addition, it contains one text input field for entering
the date of birth with mandatory input. If the user submits and no
date is entered or the date is invalid, the error is identified and
described to the user in text below the form (JavaScript adds text to
the DOM). However, screenreader users may not notice the text below
the form because the focus remains on the submit button after
"submission" (JavaScript catches the missing input, so nothing is
submitted to the server); when tabbing off the submit button, the
focus moves to the URL bar instead of to the message below the form.
We tried different variations on this technique, one of which
included a change to the text of the submit button to draw attention
to the error message, but that did not solve the focus problem.

[1] http://www.bentoweb.org/ts/XHTML1_TestSuite2/metadata/sc2.5.1_l1_025

Best regards,

Christophe Strobbe

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

We have removed the technique "Providing client-side validation and
adding error text via the DOM (future link)" until it has been
implemented and proven to work.

----------------------------------------------------------
Comment 7: Failure F70 Does not Prohibit Duplicate Attributes
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0088.html
(Issue ID: 2539)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

When we evaluated test case sc4.1.1_l1_007 [1], which contains an
image with two alt attributes (one empty, the second with a text
alternative), we found the following behaviour: if the image cannot
be loaded, Internet Explorer 6.0, Firefox 2.0, SeaMonkey 1.1 and
Opera 9.0 (all tested on Windows XP) don't display alt text. This
probably means that the second alt attribute is ignored by these browsers.

This situation is not clearly covered by success criterion 4.1.1 nor
prohibited in failure F70.

Proposal:

Add to SC 4.1.1: "start tags have no duplicate attributes."


[1] http://bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc4.1.1_l1_007


Best regards,

Christophe Strobbe

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

We have updated Success Criterion 4.1.1 as follows:

4.1.1 In content implemented using markup languages, elements have
complete start and end tags, elements are nested according to their
specifications, elements do not contain duplicate attributes, and any
IDs are unique, except where the specifications allow these features.

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quotation mark, are not complete.

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