- From: Joe Clark <joeclark@joeclark.org>
- Date: Thu, 2 Sep 2004 13:59:07 -0400
- To: WAI-GL <w3c-wai-gl@w3.org>
>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