Re: [1.2] issue summary and proposal

>Level 1 Success Criteria for Guideline 1.2
>1. Captions are provided for prerecorded multimedia.
>(Editorial note: Propose that we don't create exceptions, but that 
>policy makers create exceptions. Refer to Telecom Act of 1996 which 
>defines "broadcast hours" for which captions are required as well as 
>a staggered time frame for requiring captions for programs that 
>aired before 1 January 1998)

We'll need at least scoping requirements for cases of:

* very little or a whole lot of multimedia
* multimedia that will be posted only for a short time
* multimedia that is posted as an example or counterexample of 
accessible content (including learning examples)
* entire phase-in schedules

>2. Audio descriptions are provided for prerecorded multimedia.
>(Editorial note: Again, we shouldn't create policy. Policy makers 
>should create it)

We can't get past the fact that some video programming (but not 
entire genres) does not require description. We can't issue a blanket 
guideline of that sort.

>3. Transcripts are provided for prerecorded audio-only content that 
>contain dialog
>(Editorial note: this should not apply to music with lyrics. Should 
>this be an exception or is it clear enough?)

And if it's a radio show with an interview segment, then a song, then 
another interview?

>4. A text alternative is provided for live audio-only content by 
>following Guideline 1.1.
>(Editorial note: an internet radio stream would only need to provide 
>a description of the intent/character of the station, *not* every 
>song they play)

I suppose you mean dialogue-only audio. This essentially requires 
real-time captioning. Sometimes a post-facto transcript will do, but 
more importantly, even mightly WGBH can't provide standards-compliant 
ways of real-time-captioning audio. Where *do* the captions appear?

Don't make a requirement that is technically impossible to achieve right now.

>5. A text alternative is provided for live video-only content by 
>following Guideline 1.1.
>(Editorial note: webcams would only need a text alternative 
>associated with the concept that the cam is pointing at, *not* every 
>image that is captured)

I think this is going to need a much better formulation. Aren't we 
requiring captioning and, in some cases, description? You can use 
<embed> in compliant methods, but <embed>, unlike <object>, does not 
include text equivalents.

And do you mean "equivalent" or "alternative"?

>5. Applications that contain multimedia should follow Guidelines 4.1 and 4.2
>
>Level 2 Success Criteria for Guideline 1.2
>1. Real-time captions are provided for live multimedia

We already have that above.

>Level 3 Success Criteria for Guideline 1.2
>1. Sign Language interpretations are provided for multimedia (either 
>real-time or prerecorded) in the language of the dialog

NO NO NO NO NO.

* WCAG cannot require translations. Where does that end? Can 
Ukrainians require that all Web pages carry Ukrainian translations?
* Sign languages are by definition not "in the language of the 
dialog[ue]." There is no dialogue in sign language.

>audio description
>Audio descriptions provide access to multimedia for people who are 
>blind or visually impaired by adding narration that describes 
>actions, characters, scene changes and on-screen text that can not 
>be determined from listening only to the soundtrack. This narration 
>is limited to pauses in dialog and provided in the spoken language 
>of the audio.

<dfn>audio description</dfn>
Additional audio narration that explains important details that 
cannot be understood from the main soundtrack alone.

>captions
>Captions provide access to multimedia for people who are deaf or 
>hard of hearing by converting a program's dialogue, sound effects, 
>and narration into words that appear on the screen. Captions are 
>rendered in the written language of the audio.

<dfn>captions</dfn>
Synchronized transcript of dialogue and important sound effects.

>live
>The events are occurring in real-time as the user is watching or 
>participating.

There's the problem here that someone may want to post an audio file 
and a transcript later. Strict reading of WCAG would force them to 
hold off for hours or days until the transcript is done.


-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Expect criticism if you top-post

Received on Thursday, 2 September 2004 17:59:23 UTC