Re: Comments on WCAG 2 Requirements

Gregg Vanderheiden wrote:
> 
[snipped editorial suggestions on #1]

> RE; SUGGESTION #2   - REMOVING NUMBERS FOR DELETED ITEMS FROM APPENDIX
> We cannot change the numbering without scrambling the record of
> discussion in the archives.   So we just leave them like this.    True
> it provides no information - but if there is no harm, then I think we
> should leave them because renumbering would remove information from the
> others (when renumbered) and deleting the numbers leaves one wondering
> if something got dropped by accident.   Make sense now?  Or do you still
> think they should be removed?

I still think they should be removed since there's no information
except somehow if you've followed the pre-history of the document.
So presumably, this information is only for WG participants. How
about a note in the next version that says "The following issues
were subsumed: Nx, Ny, .... Please refer to the WG issues list
(or archives or wherever this information is found) for information
about these issues."

Otherwise they distracted me more than if some numbers had
been skipped.

[snip]

> RE SUGGESTION #4 and #5 ABOUT COMBINING AND REWORDING
> First, these are not requirements.  They are just statements of
> consensus.  We do not spend a lot of time wordsmithing them since they
> are not the deliverable.   Only things we agreed to and wrote down for
> guidance and communication.  (and memory).  Often the statements
> referred to are arrived at during successive discussions.  So they are
> piecemeal sometimes.   Unless there is a problem we usually don't go
> back and clean up grammar or style.    If you see a problem - then we
> need to address these.  Otherwise they are just internal communication
> items that we share externally so people can track what we are thinking.
> Is there a problem with these?  if so please repost.   Thanks

Both of my suggestions #4 and #5 reflect my confusion about
statements in the requirements documents, and therefore I do think
those statements should be reviewed.

The metadata comments confused me. The comment about being
able to choose to not satisfy a checkpoint concerned me since it
seems inconsistent with conformance (unless it isn't inconsistent,
but that's not clear from the document).

> RE SUGGESTION #6  - CAN BE OBTAINED FROM THE SAME URI
> Your suggestion of having all the versions available from the same home
> page does satisfy this item.   As does having an "accessible version"
> link off of an inaccessible page - as long as the link is accessible.
> So I'm not sure you do disagree.  Do you?

Here's what I think I understand:

  a) For some users, alternatives will be necessary.
  b) In terms of WCAG 2.0, it doesn't matter whether the alternatives
     reside on the client-side or server-side, as long as the user
     can get them.

What is confusing is the expression "at the same URI". I first
read this to mean "by dereferencing a single URI" (which implied
content negotiation) rather than as "there must be a single Web
page that includes links to all alternatives" (or something 
similar). Thus, I think clarification is necessary.

Meanwhile, if I were to rate the requirement, I would give it
a P2. It seems like a P1 that the alternatives exist (and perhaps
I should have to provide URIs to all alternatives in a conformance
claim). It seems like a P2 to have access to all alternatives from
a single location.

  _ Ian

> ------------------------------------
> Gregg Vanderheiden Ph.D.
> Ind Engr - Biomed - Trace,  Univ of Wis
> gv@trace.wisc.edu
> 
>  
> 
> 
>  -----Original Message-----
>  From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
> Behalf
>  Of Ian B. Jacobs
>  Sent: Tuesday, May 07, 2002 10:59 AM
>  To: w3c-wai-gl@w3.org
>  Cc: ij@w3.org
>  Subject: Comments on WCAG 2 Requirements
>  
>  Hello all,
>  
>  Congratulations on the publication of Requirements
>  for WCAG 2.0 [1]. I wish the group continued
>  progress. I have a couple of comments below.
>  
>    - Ian
>  
>  [1] http://www.w3.org/TR/2002/WD-wcag2-req-20020426
>  
>  1) Section 6: "Therefore, WCAG 2.0 must not completely change the
>                  definition of accessible content."
>  
>      The WCAG 1.0 defines "accessible [content]" to be:
>  
>       "Content is accessible when it may be used by someone with a
>        disability."
>  
>      This seems pretty immutable to me. Perhaps what section 6 should
>      say is "Therefore, what WCAG 2.0 requires and what WCAG 1.0
>      requires must not differ substantially."
>  
>      As usual, I prefer avoiding the "definition" of accessible
>      content and instead leaning on the set of requirements that
>      makes up WCAG 1.0 or 2.0. I think it's quite sufficient to say:
>  
>      a) WCAG X defines a set of requirements that, if met, will reduce
>         barriers to accessibility for some users.
>  
>      b) Therefore, conformance to WCAG X is very likely to improve
>         accessibility for many users.
>  
>      c) Conformance is not a guarantee of accessibility.
>  
>      d) "Accessible" means can be used by a person with a disability.
>  
>  2) Appendix A, Section "N": The entries that are deleted due to
>      changes in structure (e.g., N1, N3, ...) are not useful because
>      there is no context and no links. I suggest just getting rid of
>      them unless there's some background why they were there in the
>      first place. At least put the titles of the things that were
>      deleted; as is there is no useful information.
>  
>  3) Appendix A, C4: "Should not be able to claim conformance by
>      disability." I suggest that this be merged with C5. Please
>      clarify in the document why conformance based on disability
>      is considered a bad thing.
>  
>  4) Appendix A, M1: "It should be possible to use metadata to claim
>      conformance". All claims are (represented in) metadata (whether
>      in English, HTML, RDF, etc.). I'm not sure what this requirement
>      means. The next entry (M2) hints at machine-readable formats,
>      which is what I thought M1 was about. I suggest merging M1
>      and M2 into something like:
>  
>      "Claimants should be able to represent their conformance claims
>       using either a (primarily) human-readable format or a
>       machine-readable format. The Working Group does not yet know
>       whether a machine-readable format should always be required."
>  
>      I suggest strongly *not* requiring a machine-readable format
>      for every claim. The TAG has been discussing whether all
>      namespace documents should include machine-readable or
>      human-readable information or both. Since there are many
>      applications when one or the other is preferable, the TAG is
>      making no absolute requirement (for now); they are simply
>      indicating the advantages of each.
>  
>  5) Appendix A, M4: "It should be possible for authors to decide
>      not to implement a particular checkpoint." This is very
>      much in the UAAG 1.0 model: indicate what you don't do in the
>      claim. However, it is not possible to exclude a checkpoint
>      "arbitrarily" and still conform. Please clarify in M4 that
>      excluding a checkpoint based on author's decision means the
>      content doesn't conform. (Unless that's not what's intended,
>      in which case I don't understand how conformance will work.)
>  
>  6) Appendix A, S1: "can be obtained by visiting the same URI".
>      This seems unnecessarily strict. This implies that content
>      negotiation is required, and I don't think that's necessary
>      (I oppose this requirement). I think that if there are 10
>      versions of content, and all 10 links are available from some
>      home page, that meets the accessibility need. If you really mean
>      that content negotiation is required, please provide very clear
>      rationale.
>  
>  --
>  Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
>  Tel:                     +1 718 260-9447
> 



-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Wednesday, 8 May 2002 01:13:21 UTC