Re: Shifting gears for a second (was RE: Codecs for <video> and <audio>)

John


overall I share your frustration over the lack of a discussion on 
accessibility of media.  I've tried to start a discussion more than 
once, but it has always fizzled.

It's tempting to jump right in and say "let's pick a captioning 
format!", but I think it's better to step back and ask questions like

"how do we go about selecting or configuring the media experience to 
meet accessibility needs?" (so, for example, one of the alternative 
sources might have a caption track that can be enabled, and if a user 
needs captions, we should try to pick that source and enable them),

"can we detect user preferences, the existence of accessibility 
provisions in media, and extract some of it? (e.g. text in captions)",

"can we associated timed media with appropriate additional or 
alternative material (such as a transcript)?"


More comments inline below.


At 23:02  -0700 2/07/09, jfoliot@stanford.edu wrote:
>
>Will end users be able to 'extract' the text from the media asset 
>for repurposing (for example to Braille output device)? Will it 
>allow for text resizing (for low vision users), or re-styling via 
>CSS (adjusting foreground/background contrast aiding low vision and 
>dyslexic users, etc.)? It would be very interesting to see the full 
>proposal if it is public.

We're working on a framework to do that in the media annotations 
group (it's more general, but I hope it will apply to this case).

>
>>(2) Alternate video files with "burned in" captions, selected 
>>according to user preferences and using the media="" attribute of 
>>the <source> element, with some extensions we have proposed for 
>>accessibility preferences. (*)
>
>While it is hard to be upset with a full-on accessibility strategy 
>(so don't misunderstand me), I suspect that this type of involved 
>solution would see little uptake from majority web developers. 
>Unless you are suggesting that sometimes specialty solutions *are* 
>acceptable... [mischevious grin]. However it is great news to hear 
>that Apple for one is pushing the envelope here.
>
>Based upon first hand experience it needs to be as simple and as 
>straight forward as possible, especially if it (captioning) is to 
>scale up at the author end. As well, currently (at least in my 
>experience) the transcription and time stamping happens in an 
>asychronous fashion to the video production, with the caption file 
>taking as much as 5 days to "catch up" to the media asset - sort of 
>"better late than never"; again this supports the out-of-band 
>solution as being preferable, as it reflects current author 
>practice. Silvia Pfeiffer's work earlier this year with the Ogg Kate 
>wrapper (while beyond my technical expertise) seemed to offer a 
>workable dual solution (link currently unavailable as I am typing 
>this at 30,000 feet)

I'm not sure what you are saying here.  Lots of file formats have 
provision for carrying captions, and SMIL can be used to make a 'par' 
that has media and captions.  In addition, I think the HTML5 cue 
range support could be used to trigger caption display from e.g. a 
downloaded text file.

I want to get it to the point where these two scenarios work easily, 
and I don't think it's rocket science:
a) the content provider uses a format where accessibility provisions 
are easily enabled or disabled at the client; it should be possible 
for media to be configured automatically to the user's normal 
preferences, and it should be possible to build e.g. a script to 
provide manual feedback of what's available and control it.

b) the content provider has a format or content where the 
accessibility is not run-time configurable, or alternative versions 
of the content are needed (e.g. the audio has been re-authored to 
provide video description).  It should be simple for the UA to select 
the alternative source that most closely matches the user's needs.


-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Friday, 3 July 2009 08:34:20 UTC