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

Received on Monday, 7 August 2000 00:22:55 UTC