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

Dear EOWG,

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: Allow users to filter out HTML techniques
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0118.html
(Issue ID: 2567)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

suggested revision: allow users to filter out HTML techniques

rationale: lets users filter out a bunch of info that is not necessary
in certain use cases, e.g., wanting to look up only multimedia or CSS
related issues. (note that several EOWG participants tried to do this
and were overwhelmed with the number of techniques still listed.)

Proposed Change:
Allow users to filter out HTML techniques.

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

The way the document is currently set up, it breaks if we try to do
this. We will add this suggestion to a to-do list for future
consideration. In the meantime, authors can use the listing of
techniques by technology to view all of the techniques available for a
given technology.

----------------------------------------------------------
Comment 2: List all contributors to WCAG 2.0
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0120.html
(Issue ID: 2569)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Suggest including *everyone* who has made a contribution to WCAG2.0 -
1500 comments?

Rationale: Gives strong authority to the document.

Proposed Change:
Suggest including *everyone* who has made a contribution to WCAG2.0,
including those who submitted comments. Could be pulled off into
another page.

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

We would have to get permission from everyone to do this. Some who
have commented may not want their names on the document.

We will look into creating a separate page on the Web site to list all
of the commenters.

----------------------------------------------------------
Comment 3: Typos in Programmatically determiend
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0121.html
(Issue ID: 2570)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Definition - Programmatically determiend

Spelling error: determined

Capitalisation inconsistency: should be lower case for consistent capitalisation

Proposed Change:
fix spelling typo and make lower case

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

Thank you. These typos have been fixed.

----------------------------------------------------------
Comment 4: changes of context definition
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0122.html
(Issue ID: 2571)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Definition - changes of context

Should these not be examples rather than a complete definition? - I
can't think of another context, but doesn't mean that one won't be
developed eventually.

Proposed Change:
provide a complete definition, and use what's there as examples

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

We have revised the definition as follows:

changes of context
 major changes in the content of the Web page that, if made without
user awareness, can disorient users who are not able to view the
entire page simultaneously

Changes in context include changes of:

       1. user agent;
       2. viewport;
       3. focus;
       4. content that changes the meaning of the Web page.

    Note: A change of content is not always a change of context.
Changes in content, such as an expanding outline or dynamic menu, do
not necessarily change the context, unless they also change one of the
above (e.g. focus)

    Example: Opening a new window, moving focus to a different
component, going to a new page (including anything that would look to
a user as if they had moved to a new page) or significantly
re-arranging the content of a page are examples of changes of context.

----------------------------------------------------------
Comment 5: Clarify what 'which is optional' applies to
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0123.html
(Issue ID: 2572)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Current wording: "This section lists requirements for conformance to
WCAG 2.0 as well as information about how to make conformance claims,
which are optional. It also introduces..."

Suggested revision: "This section lists requirements for conformance
to WCAG 2.0. It also gives information about how to make conformance
claims, which are optional, and introduces..."

Rationale: it could be legally argued that it the current form leaves
it ambiguous as to whether the phrase 'which is optional' applies to
the second phrase of the sentence, or the first and second. We don't
think that this is a comprehension problem, yet a potential legal one.

Proposed Change:
Suggested revision: "This section lists requirements for conformance
to WCAG 2.0. It also gives information about how to make conformance
claims, which are optional, and introduces..."

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

We have updated the text to read as follows:

This section lists requirements for conformance to WCAG 2.0. It also
gives information about how to make conformance claims, which are
optional. Finally, it describes what it means for Web content
technologies to be accessibility-supported, since only
accessibility-supported technologies can be relied on for conformance.
Understanding Conformance includes further explanation of the
accessibility-supported concept.

----------------------------------------------------------
Comment 6: Remove rationale from Guideline 1.1 text
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0124.html
(Issue ID: 2573)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

current wording: "Guideline 1.1 Text Alternatives: 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"

suggested revision: remove the extra text

Rationale: "so that it can be changed into other forms people need,
such as large print, braille, speech, symbols or simpler language" is
the rationale behind the guideline and therefore should not be
included in the guideline text for several reasons, including:

- the rationale isn't included in the text of the other guidelines or SC

- the extra wording makes it more complex to parse the guideline text

- it could encourage the guideline to be interpreted to be restricted
to the cases listed

- it is easier to skim the documents without the additional rationale
in the guideline text

- (and, many people know this already)

Proposed Change:
"Guideline 1.1 Text Alternatives: Provide text alternatives for any
non-text content"

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

You are correct that this guideline is different than most of the
others in that it includes explanatory text.  This was done because
the guideline is so important across disabilities and is so often
misunderstood as to its purpose. The understanding document does cover
this, but these guidelines appear in many places by themselves. The
text is important to understanding not only the guideline but the
success criteria under it.

We could have written it with "such that" rather than "so that" and it
would then have been clearer that the text must allow all these things
to be done.  But, it was harder to read with that language.


----------------------------------------------------------
Comment 7: Link 'metadata'
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0125.html
(Issue ID: 2574)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

current wording: "Metadata may assist users in finding content most
suitable for their needs."

suggested revision: "_Metadata_ may assist users in finding content
most suitable for their needs." with "metadata" linked to a definition
or location where it is explained.

Rationale: metadata is a technical term/jargon and needs linking to a
definition or explanation

Proposed Change:
"_Metadata_ may assist users in finding content most suitable for
their needs." with "metadata" linked to a definition or location where
it is explained.

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

We have added the link as proposed.

----------------------------------------------------------
Comment 8: "Item Number': Abstract. clarify with commas
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0126.html
(Issue ID: 2575)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

current wording: "Guidance about satisfying the Success Criteria in
specific technologies as well as general information about
interpreting the Success Criteria are provided in separate documents."

suggested revision: add commas

rationale: makes this sentence easier to parse.

Proposed Change:
"Guidance about satisfying the Success Criteria in specific
technologies, as well as general information about interpreting the
Success Criteria, are provided in separate documents."

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

We have inserted the commas as proposed.

----------------------------------------------------------
Comment 9: Add header to first page
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0127.html
(Issue ID: 2576)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Add the header that is on the subpages to the first page
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/>

Rationale: Provide consistent navigation and design across different
Web pages in the same document. Reinforce that the pages are related.

Proposed Change:
Include the header that is on the subpages on the first page
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/> (with "Understanding WCAG
2.0" at the top left and 'buttons' for Intro and Next...)

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

The subtitle (actually running head title) on the sub pages is on the
first page - but it is the title of the first page.  We are not
repeating it as a running head on the main page because it would mean
the title would appear twice at the top of the page - especially for
screen reader users this could be confusing to hear.

----------------------------------------------------------
Comment 10: Change "accessibility supported" to "accessibility-supporting"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0129.html
(Issue ID: 2577)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Several in EOWG continue to feel strongly that it should be
"accessibility-supporting technologies". Here are two perspectives on
this issue:

What is doing what to what? I *think* it's that technologies such as
HTML and CSS are supporting accessibility in that they give structures
that are available to AT to provide data about relationships within
content.

<excerpt>'Here is how I think the WCAG WG is thinking of it:
"Accessibility supporting" would talk about what the technology does.
That is, it supports accessibility. "Accessibility supported" refers
to what has been done to (or is true of) a technology. That is, that
there is accessibility support FOR the technology. We mean the latter
not the former. So "accessibility supported" would be the correct term
and would be hyphenated whenever used as an adjective.'</excerpt>

So let's unpack this. Is it true that HTML is accessibility-supported?
That is the same as saying that HTML is supported by accessibility.
I'm not sure that "HTML is supported *by* accessibility" is a
meaningful phrase. "HTML or CSS provides support for AT" would be
meaningful. But it doesn't do what we want to do, which is to
differentiate between technologies that remove accessibility barriers
and technologies that don't.

Consider a fictional new content delivery technology, let's call it
PEBKAC. PEBKAC has some integral accessibility features, but these are
not supported by users' assistive technologies, nor by current
browsers and other user agents. Where is the 'accessibility'? Is it
sitting in PEBCAK, unsupported by AT? Or is it sitting in the AT,
unsupported by PEBKAC? Or is it an emergent property of the link
between the two?

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

Yes - HTML is supported by accessibility tools (that is, it is
supported by assistive technology and access features in user agents).
The key to the guidelines is that the technologies that are used will
work with and are supported by assistive technologies and access
features in other user agents. If they are not supported, then users
cannot access the information encoded in the technologies even if the
technologies support accessibility (e.g. provide ways for AT to access
them). It is the support by assistive technology that makes the
technologies and the content in them usable by people with
disabilities.

In your example, PEBKAC is accessibility-supporting but it is not
accessibility-supported because there is no assistive technology that
supports it.

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