W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > May 2007

Your comments on WCAG 2.0 Last Call Draft of April 2006

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:42:47 -0700
Message-ID: <824e742c0705171642gc3e699el37d4ed11c92f2f05@mail.gmail.com>
To: "Rick Hill" <rrhill@ucdavis.edu>
Cc: public-comments-WCAG20@w3.org

Dear Rick Hill  ,

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/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-830)

2. Being able to define entire directories of your site as off-limits
to accessibility should only be allowed when the content cannot be
made accessible.

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

The "Scope out" language has been removed. Conformance claims must
describe the set of Web pages covered by the claim.

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

Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-831)

3. The compliance "levels" do not seem to have become simpler.
Perhaps more cryptic. And I would like to see a move toward
enforcible standrads rather than merely guidelines (as in what was
attempted with the language of 508).

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

The description of conformance levels in WCAG 2 has been rewritten to
clarify the differences (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):

"The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.

*In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.

*The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.

*Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content."

We have made testability a high priority in WCAG 2, in hopes of
gaining some of the benefits of a standard versus a guideline.

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-832)

6. It would seem that WCAG 2 proposes maintaining separate accessible
and inaccessible versions of the same pages.

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

WCAG 2 does not promote the idea of maintaining separate accessible
and inaccessible versions of the same pages, but does not prohibit
maintaining separate accessible and inaccessible versions of the same
pages as this accommodates the provision of versions of pages
optimized for use by people with specific disabilities.
Authors may use technologies that are not accessibility-supported Web
technologies provided that the authors do not rely upon those
technologies for conveying any information or functionality. That is,
the information and functionality provided through the non-qualifying
technology is also provided using accessibility-supported Web
technologies. In addition, the presence of content in the
non-accessibility-supported technology must not block the ability of
the users to access the content via the accessible technologies. More
information can be found on this in the Conformance section,
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#conformance .



----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-833)

5. Source order must match presentation order even at the lowest
level ... why?

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

SC 1.3.3 does not require that the source code order match the
presentation order, it requires that it be possible to
programmatically determine at least one sequence of the content that
makes sense. Making the source code order match the presentation order
(assuming the presentation order makes sense) would be a sufficient
technique, at least in HTML. However, if the technology supports it,
other techniques to achieve this objective would also be sufficient,
some of which are listed. Source code order is not currently listed as
a sufficient technique and has specifically been de-emphasized by the
Working Group.

----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-829)

1. The provision to define a technology as a "baseline"  is not
useful unless there is either some way to make sure that the
technology is inherently accessible and/or that there are provisions
to provide alternate technologies to provide accessible versions of
the content where the baseline technology fails.

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

Even if a technology contains features that are not accessiblity
supported, it can still be possible to produce conforming content as
long as those features do not occur in the content.  For example,
let's imagine a technology that fully conforms to WCAG 2.0 with the
only exception that non-text content cannot be supported with
alternative text.  You may not logically expect to see this technology
used in a WCAG 2.0 compliance site.  But the author can use this
technology and claim conformance if there is no non-text content of
this technology in the web pages.

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu
(Issue ID: LC-834)

4. You can't use offscreen positioning to add labels (e.g., to forms)
that only some people, like users of assistive technology, can
perceive. Everybody has to see them.

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

This technique describes a way to add hidden text to links, not to add
labels to form fields. For links, this can be useful when sighted
users are using the context of a link to interpret its text, but the
context is not easily available to users of assistive technology.

We agree that it is not appropriate to use such a technique for adding
labels to forms.
Received on Thursday, 17 May 2007 23:43:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:07 UTC