- From: Justin James <j_james@mindspring.com>
- Date: Mon, 1 Sep 2008 13:42:00 -0400
- To: "'Lachlan Hunt'" <lachlan.hunt@lachy.id.au>, "'Philip TAYLOR'" <P.Taylor@Rhul.Ac.Uk>
- Cc: "'Anne van Kesteren'" <annevk@opera.com>, "'Boris Zbarsky'" <bzbarsky@mit.edu>, "'HTML WG'" <public-html@w3.org>
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