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

Hi Loretta and Working Group members,

Thank you for responding to my comments regarding the December 07 Draft 
of WCAG 2.0 and for all your hard work in consulting on and developing 
the Guidelines.

Please see my "Response to Response from Working Group" below for each 
of the original comments.

Kind regards,
Sandra.



Loretta Guarino Reid wrote:
> 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.

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

Thanks - that sounds encouraging. I'll await developments.

> 
> ----------------------------------------------------------
> 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.
> 
  ---------------------------------------------
  Response to Response from Working Group:
  ---------------------------------------------

Thanks. I appreciate the difficulty in renaming advisory techniques and 
the importance given to them in the WCAG 2.0 Introduction. However, my 
concern is still that they are "advisory" only, yet many are required to 
make websites accessible with today's user agents and necessary from a 
'usable accessibility' perspective.

I'm wondering if this is perhaps a result of limiting the definition of 
accessibility to what is testable in the normative guidelines and 
therefore they are not or can not be 'sufficient'.

I would like to see a stronger reference in the normative document that 
states the requirement for both testability and qualitative 
accessibility criteria in claiming accessibility conformance but 
appreciate the W3C efforts to date in encouraging authors to view and 
apply all layers of guidance.

Received on Thursday, 3 April 2008 01:15:41 UTC