Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Jim Thatcher ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the 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 updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

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:

Source: http://www.w3.org/mid/20060524141745.36CE0DAFC5@w3c4-bis.w3.org
(Issue ID: LC-587)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

I am doing final copy editing of a book chapter on forms.

I had talked about how clear the January version of WCAG20 was about forms:

SC 4.1.3 The label of each user interface control in the Web content
that accepts input from the user can be programmatically determined
and is explicitly associated with the control.

But now that has apparently been replaced by:

SC 4.1.2 For all user interface components, the name and role can be
programmatically determined, values that can be set by the user can be
programmatically set, and notification of changes to these items is
available to user agents, including assistive technologies.

The problem is that 4.1.2 is absolutely inadequate. The \"Role\" of
text input field is \"text input\"; the name could be \"keyinput\".
4.1.2 is basic software accessibility - leaving to the AT the process
of figuring out what the prompt (label) is.

I just talked with John (who sounds terrific) and he pointed out that -

1.3.1 Information and relationships conveyed through presentation can
be programmatically determined, and notification of changes to these
is available to user agents, including assistive technologies.

Served the same purpose as 4.1.3 - I agree. But it is abstract. It
requires interpretation.

With the Last Call version of WCAG 2.0 there is no success criterion
that specifically addresses labeling forms and I think that is a very
serious mistake.



Proposed Change:

Please reinstate 4.1.3.

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

The WG feels this requirement is properly covered under 4.1.2 and did
not wish to reinstate a SC that would be redundant with that. However,
we agree that it's difficult for users to understand that form
labeling is part of 4.1.2. We have added a failure and an advisory
technique to SC 1.3.1 and 4.1.2:

F68: Failure of 1.3.1 and 1.4.2 due to the association of label and
user interface controls not being programmatically determinable

Providing labels for text input or item selection form controls (future link)





----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/20060605135513.9D89ABDA8@w3c4.w3.org
(Issue ID: LC-713)

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

I had a talk with John Slatin about 4.2.2 on 5.21.2006. It is clear
that what he was looking for:

\"The goal was to permit the user to explore the context without
needing to navigate away from the link.\"

This is an admirable and very understandable user goal.

But I think it is impossible to build this requirement build into a
success criterion. Using a phrase like "Programmatically associated"
without defining it – doesn't solve the problem.

Screen Reader/2 for OS/2 had a key command that allowed the user to
"save the current state" do any other command, and return to the saved
state when that completed or was stopped. So the goal of allowing the
user to explore the context is AT specific, which you mentioned,
Loretta. The point is that there is nothing structural about that
exploration. Nothing related to the current link. You could "push the
state, and read "line" 123 and be back where you were. You could read
the whole page and be back at your link.

John Slatin mentioned http://slashdot.com as an example. In this case
the context is the text above, not a paragraph; good context is the
previous heading. But with current AT – I think –you can't read the
previous heading without loosing your place – or the previous
paragraph. There are several different situations on Slashdot.com
where generic links relate to a previous text which is not a paragraph
tag – just a div.

However, with Slashdot (as John pointed out in our conversation), when
you move to the Read more link from the JAWS links list JAWS announces
the heading which is the (or a) context for the link – that's cool.
Furthermore, even though JAWS isn't as sophisticated as Screen
Reader/2 (!) you can accomplish the same kind of thing with
PlaceMarkers. When you are on the link,  press CTRL K to set a
temporary place marker, Press SHIFT H for previous heading, Press K to
return to the PlaceMarker, and you are back at the link.  So the
context is read without loosing your place.


One of my favorite examples of this problem area is the Priceline.com
hotel listing - http://tinyurl.com/qh9o2.

There is a framed block for each hotel, of maybe 30 hotels. Each hotel
block has 7 generic links, Choose, More, Features, etc., all concern
the hotel at the top of the block. Priceline uses the title attributes
to resolve this but we all know how well that is supported – the issue
here is not about the title attributes – The issue is that there is no
sensible "Programmatic association" of the hotel title to the generic
links. For each generic link there is a (different) technique for
accessing the hotel name – using a PlaceMarker. For Choose, use next
table cell (CTRL ALT RIGHT ARROW). For More, Features, ... Map, use
current table cell,(CTRL ALT UP ARROW), For the last link go up two
cells. Combine these with the CTRL K and K combination, and one is
able to explore context with out loosing the link.

The reason I am saying all this is I believe that there is nothing
special about these examples. I think it is always going to be
possible to find a combination of keys that will provide context for a
"generic link." And I think there will be no general sequence that
will work in all or even many cases. (How about setting a place marker
and moving back (up arrow) in the document? It fails for the Choose
link in the Priceline example.)

In the same way as the Priceline and Slashdot examples, the first and
third Examples of Success Criterion 2.4.4 don't necessarily have any
programmatic connection to the link itself. The important information
could just be in a div – not the same paragraph, maybe not the same
table cell. But WCAG 2.0 calls these success!

I think that 2.4.4 should be eliminated because there is no definition
of what is wanted, and I think what is wanted will always be available
anyway.


Proposed Change:

Remove SC 2.4.4.

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

We have reworded both SC 2.4.8 and SC 2.4.4 to clarify the differences
between the two as well as the sufficient techniques that meet them.
They now read:

2.4.4 The purpose of each link can be determined from the link text
and its programmatically determined link context.
2.4.8 The purpose of each link can be identified from the link text.

where "Programmatically determined link context" is defined as:

programmatically determined link context
1. Additional information that can be programmatically determined from
relationships with a link; and
2. can be extracted, combined with the link text, and presented to
users in different modalities.

Example 1: Screen readers provide commands to read the current
sentence when focus is on a link.
Example 2: Examples of information that can be extracted, combined
with link text, and presented to users in different modalities include
text that is in the same sentence, paragraph, list, or table cell as
the link or in a table header cell that is associated with the table
cell that contains the link.

Received on Thursday, 17 May 2007 23:37:14 UTC