Re: Resolutions on Changes to REQUIREMENTS DOC

I have commented on some proposals below - others are fine I think.

  Change
  "WCAG 2.0 will clearly identify the target audience of each
  requirement."
  to:

  WCAG 2.0 will clearly identify who will benefit from each requirement"

CMN Proposed: ...will clearly identify at least some groups who...

rationale: We are not, in my experience, great at developung exhaustive
lists, but it is helpful to at least demonstrate that something is required.

For example, as I understand it the need to avoid flashing content was
understood long before finishing WCAG 1 as a requirement for people with
photo-sensitive epilepsy (and to apply particularly in a certain frequency
range). Long afterwards, it became clear that this requirement was also
applicable to people with certain disabilies related to attention span and
the ability to concentrate in the presence of distractions. About the same
time I learned that it was also crucial for users of a (then widespread, and
now mostly used in South America) screenreader that simply stopped - a
typical "until user agents" type case, although not aplicable to english
language.



  --------------------------------------

  Combine A-1, A-2, and A-3 into one item that reads:

  A -1  The working group acknowledges that accessibility to everyone is
  not possible.  Our target is to make things as accessible to as many
  people as possible given then need to have practical techniques and
  criteria.  We will expend our best effort to identify techniques,
  criteria and examples that would cover the greatest range possible.

CMN Proposed: The working group acknowledges that accessibility for everyone
may not always be possible. Our target is to make things as accessible to as
many people as possible, but there is a requirement that we need to specify
in terms of verifiable requirements. We will expend our best effort to
identify techniques and examples that cover the greatest range of people we
can.

Rationale: 1. In some cases it may not be impossible either. 2. "practical"
means different things to different people, and relates heavily to
circumstances people are in. I think what we mean by it is that we have
constraints imposed by our requirements, that affect what we can propose as a
requirement. These constraints do not, however, affect what we can propose as
a technique, as I understand things.

  --------------------------------------

  ---------------------------------

  Tune up S1 so that it is clearer what is meant.  It would now read:

  S1 - Serving content in different forms in order to meet different user
  needs or preferences is an acceptable way to comply with the guidelines,
  --  as long as equivalents for all of the information are provided in
  the different forms, and it is all available from the same URI.
  (Accessible, findable links to alternate form(s) is allowed.) (Server
  side solutions are acceptable - as specified.)

CMN This still seems unclear to me as a way of phrasing what we mean. Does it
mean every version must be content-negotiated, to keep the URI the same (in
parctice this doesn't work with existing systems, where a specific version
can come from a generic, content-negotiated URI, or can come from a specific
version URI), or does it mean that it must be possible (easy?) to get from
one version to another by some means?

I therefore propose that we mark this as an issue still open until we can
produce (or the editors can propose) some wording that seems less fuzzy

Charles McCN

Received on Monday, 28 January 2002 10:16:37 UTC