W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

Re: Clarification Of Technique 1.3

From: Chris Ridpath <chris.ridpath@utoronto.ca>
Date: Mon, 14 Aug 2000 09:59:10 -0400
Message-ID: <006f01c005f7$d2610ad0$b040968e@ic.utoronto.ca>
To: "Charles McCathieNevile" <charles@w3.org>, "Wendy A Chisholm" <wendy@w3.org>
Cc: "WAI WCAG List" <w3c-wai-gl@w3.org>, <geoff_freed@wgbh.org>
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
>
>
>
Received on Monday, 14 August 2000 09:59:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:05 GMT