Re: Clarification Of Technique 1.3

Hmmm. I am absolutely opposed to this reasoning. If it is a requirement, it
is a requirement, and the fact that people don't solve the problems of
people with some kind of disability very often doesn't make it less of a
problem. Implementation of the requirements will of course take time to be
universal,  but i think we do a disservice if we produce guidelines that in
fact leave people out in the cold after all the absolute barriers have
supposedly been removed.

Otherwise we need to change the priority statement of the guidelines, which
would of course require ATAG to do a complete reassessment of how they use
WCAG - not impossible, but not to be undertaken lightly.

Charles McCN

On Mon, 14 Aug 2000, Chris Ridpath wrote:

  I also disagree with Wendy's suggestion of a variable priority:
  
  WC: "Priority 1 if the  visual track of the multimedia is important for
  understanding the surrounding content, otherwise Priority 2"
  
  Instead I think that for practical reasons we should change this from a
  priority 1 to a priority 2.
  
  My backwards logic is: Almost all multimedia require an audio description (I
  argue that the visual track is almost always necessary for understanding the
  context). Almost no multimedia have an audio description (difficult to
  create and sync). Therefore almost all sites that include multimedia will
  fail the A rating. This can degrade the authority of the WAI guidelines.
  
  If we keep this as a priority 1 it places a heavy burden on the content
  creators. If we move it to priority 2 and perhaps move it to priority 1 in
  the future then it may be more practical.
  
  Chris
  
  ----- Original Message -----
  From: "Charles McCathieNevile" <charles@w3.org>
  To: "Wendy A Chisholm" <wendy@w3.org>
  Cc: "Chris Ridpath" <chris.ridpath@utoronto.ca>; "WAI WCAG List"
  <w3c-wai-gl@w3.org>; <geoff_freed@wgbh.org>
  Sent: Monday, August 07, 2000 12:20 AM
  Subject: Re: Clarification Of Technique 1.3
  
  
  > I don't think so for two reasons. The simpler is that the checkpoint
  already
  > says it applies to important information, and i have approached the
  second,
  > and to me more important, at length below.
  >
  > As a sometime content developer I need a couple of things from WCAG.
  >
  > The most important is guidance on what to do in given sets of
  circumstances.
  > The better this is, the simpler my life is - I look up my circumstance and
  > find the answer. I expect this to be really clear in the techniques
  documents
  > - the value of the techniques stuff by topic rather than checkpoint or
  > language lies in how well it meets this requirement. (The
  > techniques-by-checkpoint provide an idea of how to test, and a reality
  check
  > for redundancy in developing the guidelines themselves.)
  >
  > The other thing I need is a clear theoretical framework. If I can't find
  my
  > situation (and I bet that my music language isn't included in the
  techniques
  > for a while) then can I find an explanation of the requirement that is
  being
  > provided? Can I find that expressed in checkpoints - testable
  requirements?
  >
  > As a content developer I need a few other things (not least of which is
  > content <grin/>).
  >
  > I need a plan of implementation - what are my resources, how am I going to
  > develop my content and my website. What corners am I going to cut, what
  > standards do I need to meet, what are my deadlines and resource
  constraints?
  > This is not something I should look to WCAG to provide, nor to assume,
  since
  > I do not expect the group to be experts in developing the best single
  > methodology. In some sense I expect WCAG to be les dependent on technology
  > than my plans - I implement in XML, or in my own data format and
  presentation
  > system, according to my needs.
  >
  > There is in WCAG a preference for W3C technologies where available - this
  is
  > specified for good reasons when it appliess, but it doesn't always. Do I
  use
  > SMIL for music, thereby relying on non-W3C technology for content, or do I
  > use an XML/RDF based music language? How do these meet (or not) the
  > requirements of the checkpoint or of accessibility?
  >
  > I need to understand my content. What is all the information I am trying
  to
  > convey? What is purely decorative and what is integral? I certainly don't
  > expect WCAG guidelines to provide that understanding. Although I expect
  that
  > the theoretical information will assist me in clarifying that, and I
  expect
  > the techniques to have discussion and examples I can draw on.
  >
  > Where does this lead?
  >
  > The guidelines have checkpoints presented according to a set of
  priorities.
  > The priorities are based on whether or not a user has access to the
  > information I am presenting. I think this is the only sensible criterion
  for
  > the guidelines to use.
  >
  > In order to provide access to the information, I need to do certain
  things.
  > In the heady pressure of the real world I may make decisions about things
  > that are not important based on the "implementation cost", but there is no
  > reason for WCAG to suggest that I am doing anything except precluding
  access
  > (or making it harder) where that is a result of the decision.
  >
  > If information is to be conveyed, WCAG should tell me how to do that. If
  > there is extra content that is not important (decorative elements,
  stylistic
  > presentation) to understanding the information being conveyed, then I can
  > meet WCAG without providing the rest in a way that anyone can make use of
  > it. Why is it important to provide that anyway?
  >
  > If it isn't, then there is no need for a split priority. If it is, then
  how
  > does it go from being impossible to merely difficult to use my content?
  >
  > This raises the question of "what is the content?" to one of crucial
  > importance for assessing conformance. Which brings us back to Cynthia's
  > discussion of black-box testing - can relevant tasks be performed by a
  user
  > (regardless of disability)?
  >
  > So I am uneasy about having shifting priorities in this sort of case.
  >
  > Charles
  >
  > On Fri, 4 Aug 2000, Wendy A Chisholm wrote:
  >
  >
  >   CMN:
  >   >The question of context is in large part one of implementation
  priority - in
  >   >order to make something accessible it does depend to a certain extent
  on what
  >   >the context is, because in some contexts a full understanding or full
  >   >equivalent is not really necessary, and in others it is important to
  get as
  >   >close an equivalent as possible. (Think of the different uses of alt,
  title
  >   >and longdesc for an image as one example of this).
  >   >
  >   >This is an area where accessibility requires considerable thought,
  skill, or
  >   >experience to do well. (As is writing a music video in the first
  place.)
  >   >Fortunately, the actual technical barriers are much lower. So in order
  to
  >   >make these things accessible there is some work to be done. Should we
  do that
  >   >work in all cases? Of course. Which part to do first? That's a
  case-by-case
  >   >question.
  >
  >   WC:: Perhaps we need to use a relative priority along the lines of what
  we
  >   did for 8.1
  >   <Q>
  >     Make programmatic elements  such as scripts and applets directly
  >   accessible or compatible with assistive technologies [Priority 1 if
  >   functionality is important and not presented elsewhere, otherwise
  Priority 2.]
  >   </Q>
  >
  >   Thus, an entry in the WCAG for Checkpoint 1.3 would read:
  >   <Q>
  >   1.3 Until user agents can automatically read aloud the text equivalent
  of a
  >   visual track,  provide an auditory description of the important
  information
  >   of the visual track of a multimedia presentation.   [Priority 1 if the
  >   visual track of the multimedia is important for understanding the
  >   surrounding content, otherwise Priority 2]
  >   </Q>
  >
  >   That's probably not the smoothest wording, but I hope you get the drift.
  >
  >   thoughts?
  >   --wendy
  >
  >
  >
  

-- 
--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Monday, 14 August 2000 12:05:15 UTC