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

Dear Sandra Vassallo,

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: accessibility supported definition and concept is confusing
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0034.html
(Issue ID: 2412)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

I am still unsure about how accessibility supported will work and what
it means in practice.

The way it is currently described in the introduction seems confusing
and somewhat ambiguous. This may in part be due to (I think) a missing
full stop after "... Success Criteria", but even taking this into
account there is an inference that it is acceptable to use
technologies that are not accessibility supported:

<quote>

"Only "accessibility supported" technologies can be used to conform to
WCAG 2.0 Success Criteria Technologies that are not accessibility
supported (do not work with AT etc.) can be used, but cannot be used
to conform to any Success Criterion."

<end quote>

It needs to be clear that technologies that are not accessibility
supported can only be used if an accessible alternative is provided or
they will not conform to WCAG 2.0. (Note: While there are some
instances where alternative content can lead to enhanced
accessibility, in this context I continue to have reservations, since
it is being provided as a fallback to allow the use of technologies
that are not accessibility supported and there is a risk it will
become the norm rather than the exception with similar problems to the
old text-only pages.)

I am also unsure how "accessibility supported" will work in practice.
How easy will it be for developers to know if the technology is
accessibility supported and in what way it is supported? Who will be
responsible for determining if a technology is accessibility supported
or not? Some accessibility supported technology may also require
certain techniques to make it accessible at present or for legacy
versions â€" will these be Advisory Techniques or Sufficient
Techniques? If a recent version is accessibility supported and past
versions are only partly accessibility supported, will people with
disability be expected to purchase new software or do they have to
accept that the content is not accessible because they don't have or
can't afford the latest version?

Using accessibility supported technology is only part of the process,
as it is equally important that these technologies are implemented in
an accessible way - PDF and Flash being classic examples where the
technology is accessibility supported but the output often is not.
While I assume PDF and Flash would be considered accessibility
supported technologies, the new Adobe Digital Editions feature in
Acrobat Reader, that combines these two accessibility supported
technologies, appears to be totally inaccessible to screen readers.

Proposed Change:
1. Wording in Introduction

The meaning and implementation of "accessibility supported" in the
Introduction needs to be clearer and unambiguous.

Perhaps something like...

"Only "accessibility supported" technologies can be used to conform to
WCAG 2.0 and these must be implemented in an accessible way that meets
or satisfies the Success Criteria.

Technologies that are not accessibility supported (do not work with AT
etc) can only be used if a fully conformant version using
accessibility supported technologies is also available and satisfies
the Success Criteria. Easy access to the accessible alternative in an
accessible way is required."


2. Appendix with list of accessibility supported technologies

An authoritative list of accessibility supported technologies, that
has been independently assessed would assist this process, and could
be provided as an appendix to the normative document. Some
clarification on the level of accessibility support is needed as well.

3. Techniques

Any techniques presently required for accessibility supported
technology to conform to WCAG 2.0 need be in the Sufficient Techniques
(until they are no longer required).

The use of such techniques also needs to take into account
accessibility support for older versions of technologies for a
reasonable period.

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

1. The language you propose can be misread to say that you cannot use
technologies that are not accessibility supported.  But language that
covers this is already provided in the conformance requirements - and
in "understanding accessibility support" which is linked to from the
introduction. We feel that the conformance requirements and the
success criterion (which describe what must be true for content to be
accessible) work together to achieve the goal you describe.
Also note that what may be accessibility-supported in a controlled
environment where only a single (and perhaps not common) assistive
technology is used - may not be considered as accessibility supported
in another environment like the open internet.  Thus the working group
can not know what should be in the 'sufficient techniques' list.  The
working group is also not aware of all techniques and certainly not
new techniques that may be accessibility supported but are not known
to or documented yet by the Working group (so they could not be in the
sufficient list).

2. The working group recognizes that the need for information on which
technologies are 'accessibility-supported' is important to use of the
guidelines.

Such data can only come from testing different versions of user
agents and assistive technology and recording whether the features of
the technology are supported. We expect that this information may
need to be compiled from multiple sources. WAI will be working with
others to establish an approach for collecting information on the
accessibility support of various technologies by different user
agents and assistive technologies.

WCAG 2.0 is still in development. We expect that during Candidate
Recommendation period we will have some initial information on
accessibility supported technologies, to demonstrate how this
approach will work once WCAG 2.0 becomes a W3C Recommendation.

The Candidate Recommendation process itself requires that there be
examples that demonstrate conformance. So there will certainly be some
information about accessibility supported technologies in order to get
out of the candidate recommendation stage for WCAG 2.0.

3. You are correct.   The accessibility supported technologies must be
used and must be used in a way that meets the success criteria.  This
is one of the conformance requirements.   If one uses accessibility
supported technologies - but does not use them properly (e.g. the SC
would not be met) then conformance could not be be claimed for levels
that include that SC.  Just using an accessibility-supported
technology but not using it properly would not be adequate to claim
conformance.  Note that HTML done poorly would also fail the SC.

----------------------------------------------------------
Comment 2: Clarification of advisory techniques
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0009.html
(Issue ID: 2461)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

I think the concept of advisory (optional) techniques is useful in
providing strategies for enhancing accessibility and usability however
I'm concerned that many of the techniques listed are either:

* still required to make websites accessible with today's user agents

* accessibility requirements that are not "testable" but necessary to
make websites accessible to some audiences

Proposed Change:
Some thoughts...

Introduce a new techniques category for the equivalent of "until user
agents support" concept in WCAG 1.0 (as the techniques document is not
normative and can be updated, these techniques will be flagged and
could be periodically reviewed or deleted at a later date).

Change the concept of Advisory Techniques to Qualitative Techniques or
provide a new section for Qualitative Techniques that has the same
status as the Sufficient (Quantitative) Techniques.

Reword the scoping statement to acknowledge the importance of
qualitative criteria in providing accessible websites emphasizing that
testability is only one part of the accessibility process and needs to
be supported by the Qualitative Techniques as well as user testing by
people with disability wherever possible.

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

 We cannot rename advisory techniques as qualitative since only some
of them are qualitative.  Many of the advisory techniques are just as
testable as the sufficient techniques but are advisory for a
collection of other reasons.   Techniques that are 'sufficient' are
already labeled as such.  And as advisory techniques become
'sufficient' (due to advancing technologies or user agents) they will
be promoted to 'sufficient'.   We have eliminated the 'until user
agent' phrase with this new structure - one that allows provisions to
be moved up to 'sufficient' at any time that they become sufficient to
meet one of the SC.  We agree that advisory techniques are important
to Web accessibility and we have already rewritten the introduction in
our last draft to reflect the important role of advisory techniques.

Received on Tuesday, 11 March 2008 00:21:24 UTC