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

Dear IBM,

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: ARIA1 Example Doc is XHTML, not HTML
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0135.html
(Issue ID: 2582)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

The first example says that it is HTML but the example document is
actually declared as XTHML.  It is a minor nit since the document is
using HTML techniques but it would be relatively easy to update the
sample page to use HTML 4.01 DTD rather than declaring it as XHTML.

Proposed Change:
Update the sample page to use HTML 4.01 DTD.

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

We have updated the doctype in the example to HTML 4.01 as proposed.

----------------------------------------------------------
Comment 2: SC 2.4.6 not testable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0131.html
(Issue ID: 2578)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

In the TEITAC Web and Software subcommittee, this provision was not
accepted as worded due to testability concerns.

The following wording was proposed (by Michael Cooper) as an
alternative and accepted by the subcommittee.

"The function [or purpose] of form controls must be able to be
determined from the label."

Proposed Change:
Please consider changing 2.4.6 to this wording:

"The function [or purpose] of form controls must be able to be
determined from the label."

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

We have clarified SC 2.4.6 to read: "2.4.6 Labels Descriptive:
Headings and labels describe topic or purpose."

We have added the following sentences to Understanding 2.4.6 "Labels
and headings do not need to be lengthy. A word, or even a single
character, may suffice if it provides an appropriate cue to finding
and navigating content."

----------------------------------------------------------
Comment 3: Links to How to Meet SC
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0133.html
(Issue ID: 2580)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

The following paragraph still refers to the "How to Meet" documents
rather than the Understanding Success Criterion X.X.X:

Links are provided from each Guideline in WCAG 2.0 directly to each
Understanding Guideline X.X in this document. Similarly, there is a
link from each Success Criterion in WCAG 2.0 to the How to Meet
Success Criterion X.X.X section in this document.

Proposed Change:
Change links to go to the Understanding Success Criteria X.X.X

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

We have updated this text as proposed.

----------------------------------------------------------
Comment 4: F3: Updated testing to allow Dojo
Source: (@@ archive reference missing)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Dojo uses CSS images to convey information but it also provides the
necessary information to assistive technology via ARIA. And, Dojo
detects high contrast mode and replaces the background images with
actual content when high contrast mode is detected.   However, Dojo
would fail the test in this technique since there is no option in the
test to provide the necessary alternatives.  Can we add some sort of
exception or different testing to this failure?

Proposed Change:
Change the test procedure to say:

1.      Examine all images added to the content via CSS.

2.      Check that the images do not convey important information.

3.      If an image does convey important information,  the
information is provided to assistive technologies and is also
available when the CSS image is not displayed.

If step 2 and step 3 are both false - then the failure conditions exists.

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

We accept your suggestions with the provision that it is done using
accessibility supported technology

We have updated the procedure as follows:

1.      Examine all images added to the content via CSS.

2.      Check that the images do not convey important information.

3.      If an image does convey important information,  the information is
programmatically determinable and is also available when the CSS image
is not displayed.

Expected Results:
 If step #2 and step #3 are both false, then this failure condition
applies and the content fails this Success Criterion.

----------------------------------------------------------
Comment 5: Links to ARIA out of date in ARIA4
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0136.html
(Issue ID: 2583)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

The resources links in this technique go to old versions of the ARIA documents.

Proposed Change:
Update the links to point to the most recent ARIA documents

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

We have updated the links as proposed.

----------------------------------------------------------
Comment 6: C16: Mouse hover and focus not equivalent
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0137.html
(Issue ID: 2584)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

This technique shows changing the background color or border of an
element when the mouse hovers over the element.  Mouse hover and focus
are not equivalent.   This sentence in the description is incorrect,
"Usually the focus is attained through using a mouse to hover over the
element or a keyboard to tab to the element."   Focus is NOT obtained
via mouse over.  Focus is obtained via a mouse click (although that
may also perform an action).  The test procedure also equates mouse
hover with focus.

Proposed Change:
The description and title should be updated to include hover as an
action which may be used to modify background color or border, or the
examples need to be updated to remove :hover from the CSS and the test
procedure needs to be updated to remove hover as a test case.

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

Good catch. Thank you. We have updated the description and the title.

----------------------------------------------------------
Comment 7: G60: Hard to accomplish the examples in 3 seconds
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0138.html
(Issue ID: 2585)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Regarding the examples in G60, it would be pretty hard to accomplish
some of the actions in these examples in only 3 seconds:

#Example 2: A homepage opens with a short greeting by the chairman and
then goes silent.

#Example 3: A Web page opens with instructions on how to use the page.
 - If you can speak the instructions in 3 seconds they are probably
too simple to be of use.

Proposed Change:
Perhaps update the examples with a more realistic example, though I
don't have one in mind.

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

We have changed the examples as follows:

Example 2: A homepage opens with the chairman saying "Binfor, where
quality is our business."  then going silent.

Example 3: A Web page opens with instructions on how to get started:
"To begin, press the enter key".

----------------------------------------------------------
Comment 8: G142: Version numbers should be added for Firefox
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0139.html
(Issue ID: 2586)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Version numbers should be added so the user knows which version of FF
supports zoom.

Proposed Change:
Add a version number to the Firefox statement since Firefox 3 will be
supporting zoom: "FireFox <add>2</add> supports only text size
changes, but can change the size of pt and px fonts as well as %, em
and named sizes."

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

We have added the version number as you proposed.

----------------------------------------------------------
Comment 9: C17: Technique also works in Firefox
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0140.html
(Issue ID: 2587)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Technique says it only works in IE, but it seems to work in Firefox as well.

Proposed Change:
Verify that this technique does or doesn't work in Firefox. It seems
to work when I go to view --> text size --> increase.

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

The code from example 1 works in both browsers. However, for example 2
in Firefox 2, the checkbox and radio buttons do not scale when the
text size is increased. We have updated the technique to clarify this.

----------------------------------------------------------
Comment 10: F80: Failure does not fail in Firefox
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0141.html
(Issue ID: 2588)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Failure code sample does not fail in Firefox.

Proposed Change:
It should probably be mentioned in the failure that it may not fail in
all browsers.

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

The failure says that there is a failure only when text-based form
controls do not resize when visually rendered text is resized. Because
the code sample in the failure would fail in user agents that are
commonly used today, the working group felt it was a good idea to
retain this example.

If, however, an author were making a claim for a controlled
environment such as an *intranet* where the user agents in use were
known not to fail under the conditions described in this failure, a
conformance claim could still be made.

We have added the following user agent note to this failure (same note as C12):

 When font size is specified in any absolute units of measurement,
such as points or pixels, the Text Size menu commands in Internet
Explorer 7 and earlier do not resize the text.



----------------------------------------------------------
Comment 11: F42: Programmatically determine the role not explained
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0142.html
(Issue ID: 2589)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

This failure refers to the "programmatically determined role of the
element is link" in the test procedure but there is no information
about how to "programmatically determine the role of an element" in
the rest of the document.   It would be nice to at least add a
reference to ARIA here since you could create a link from a div or
span that is accessible to assistive technology using ARIA.

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

We have added a reference to WAI-ARIA as requested.

Received on Tuesday, 11 March 2008 00:22:12 UTC