Your comments on WCAG 2.0 Public Working Draft of May, 2007

Dear UAAG,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

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 May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

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: Respecting OS keyboard accessibility features
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0374.html
(Issue ID: 2243)
----------------------------
Original Comment:
----------------------------

Under 2.1.2 it might make sense to reference respecting the operating
system keyboard accessibility settings (like StickyKeys, etc).

Proposed Change:
Consider referencing operating system keyboard accessibility settings
(like StickyKeys, etc)

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

Operating system keyboard accessibility features are controlled by the
operating system in concert with the user agent, and cannot be
overridden by Web content. However, content may generate keyboard
events that interact unpredictably with operating system keyboard
accessibility features. Therefore a paragraph has been added to
Understanding 2.1.1 to explain this.  (Understanding 2.1.2 refers the
user to Understanding 2.1.1 because the to provisions are a pair).

----------------------------------------------------------
Comment 2: "Interruptions" may warrant a higher priority
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0375.html
(Issue ID: 2244)
----------------------------
Original Comment:
----------------------------

In 2.2.5, the Intrerruptions Success Criteria is a level AAA.

Proposed Change:
Suggest Level AA.

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

This success criterion requires control of the server that may not be
possible for some authors and technologies.  There are also valid
reasons, such as financial
security or personal information where this cannot be done because it is
against regulations to preserve any of this information once a session
expires or is terminated.  It is also a new success criterion in WCAG
2.0 and there is little if any experience with the requirement and the
solutions. For these reasons the Working Group feels it is best
positioned at level AAA.

----------------------------------------------------------
Comment 3: Defintion of "programmatically determined link context"
refers to "sentence".
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0376.html
(Issue ID: 2245)
----------------------------
Original Comment:
----------------------------

There is no semantic markup for a sentence and no programmatic way for
a screen reader to determine a sentence in HTML, so its better not to
use that term. A screen reader should be able to handle the other
techniques involving parent element text, element attributes, and
element relationships.

Proposed Change:
Drop requirements involving sentence parsing.

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

Respond with:

While you are correct that there is no semantic markup for sentence,
many screenreaders provide keyboard commands which allow users to read
the current, next or previous sentence. We have added user agent
support notes to G53 that include additional detail about these
features.

----------------------------------------------------------
Comment 4: Referencing User Agents and Assistive Technologies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0377.html
(Issue ID: 2247)
----------------------------
Original Comment:
----------------------------

In "Accessibility Supported", etc. assistive technologies are often
listed before browser accessibility features. Browser accessibility
features are enhanced or supplemented by assistive technologies and
user agents transfer information to the assistive technology via APIs
etc.

Proposed Change:
In "Accessibility Supported" and throughout suggest where they are
mentionned specifically, list browsers ahead of assistive technologies
and clarify that browsers pass information on to assistive
technologies (i.e. while an assistive technology can be part of a
combination of softwares that make up a user agent, it cannot be a
user agent on its own, while a browser can).

We also suggest WCAG-WG and UAWG work together on these issues.

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

While it is true that AT works through user agents, the key part of
Accessibility Supported is support by AT for the technology.   Since
support for the technology by access features in user agents is also
important, we also list this.  But the focus is on AT support since
that is the most critical and the one most often incomplete.

----------------------------------------------------------
Comment 5: Definition of "Mechanism" needs clarification
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0378.html
(Issue ID: 2248)
----------------------------
Original Comment:
----------------------------

The definition of "Mechanism" mentions user agents but without a link.

Proposed Change:
Links to "user agent" and perhaps a connection with "Accessibility Supported".

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

Thank you. We have added the link to both "user agent" and "assistive
technologies" to the note following this definition.

Received on Sunday, 4 November 2007 02:25:27 UTC