RE: Acessibility of <audio> and <video>

I can imagine the furor if we also applied this logic to images, by saying, "if you want accessible images, use a format that natively supports metadata of alternate text, or put a subtitle/caption/legend/etc. in your image." Heads would roll. On this other hand, I also agree that it is not HTML's responsibility to pre-determine every possible accessibility scenario for every possible type of content and account for it.

A middle ground that I would like to propose, would be for @alt to be allowed on any type of non-text element, as well as @longalt (or @longdesc), and a @longalturl attribute, which would allow for an URL to be given for a FULL textual representation. For example, with an image respresenting a math formula:

<img src="formula.gif" alt="The Fibonacci Sequence" longalt="The Fibonacci Sequence expressed as a mathematical formula." longalturl="http://www.domain.com/fibonacci_text.html">

Does this make sense? Would this meet the needs for providing accessibility metadata on non-img elements, while not getting in the way of providing multimedia content?

J.Ja

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Lachlan Hunt
> Sent: Monday, September 01, 2008 11:52 AM
> To: Philip TAYLOR
> Cc: Anne van Kesteren; Boris Zbarsky; HTML WG
> Subject: Re: Acessibility of <audio> and <video>
> 
> 
> Philip TAYLOR wrote:
> > Anne van Kesteren wrote:
> >> At that point authors don't have to do much more than <video
> >> src=geweldig></video> and make sure the geweldig resource is
> >> accessible.
> >
> > This is passing the buck.  Scenario : the Principal addresses the
> > University and his address is recorded; his aide asks the webmaster
> > to put the video up on the web.  The webmaster looks at the video and
> > finds there are no closed-captions, no subtitles, no accessibility
> > features at all.  What is he to do ?  Refuse to put it up.  That
> > would be a brave webmaster indeed.  No, instead he puts it up, then
> > relies on the intelligent design of HTML 5 to allow him to add
> > accessibility features to overcome the deficiencies of the raw
> > material. And it is our responsibility to make sure that he can do
> > this.
> 
> HTML should not be relied upon as the ultimate solution to all
> accessibility issues for all the different types of media that might be
> embedded in a page.
> 
> Consider your above scenario, but instead of a video, it's some
> Flash-based media.  It is the responsibility of the person creating a
> Flash to make it accessible using Flash's accessibility features.  When
> working in a web development team, the person building the HTML is
> often
> different from the person creating the Flash.  Although it is often the
> HTML developer's job to integrate it into the page, it can't be the
> HTML
> developer's job to compensate for the Flash developer's failure to make
> use of Flash's accessibility features.
> 
> Likewise, it is the responsibility of the person on the team creating,
> editing and compressing the video for the web, to make it accessible
> by,
> for example, including a subtitle stream.  This is not too difficult
> for
> to do.  Writing subtitles in, for example, SRT format and muxing them
> into an appropriate container format can be done with freely available
> tools.
> 
> Another possible solution is to provide description/transcript of the
> video.  But such a thing is useful for more than just people without
> support for video, and providing a link to such a thing nearby that is
> available to everyone is a much better approach than trying to stick
> the
> transcript within the video element, where it is only available to
> people without video enabled.
> 
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/

Received on Monday, 1 September 2008 17:42:55 UTC