- From: Philip TAYLOR <P.Taylor@Rhul.Ac.Uk>
- Date: Mon, 01 Sep 2008 17:50:02 +0100
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: Anne van Kesteren <annevk@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, HTML WG <public-html@w3.org>
Lachlan Hunt wrote: > 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. Agreed. But it is the responsibility of the person embedding the Flash into the web page to ensure that the <stress>web page</> is accessible, even if some of its component parts are not. Thus the person carrying out the embedding would need to ensure that the Flash content was embedded in such a way as to provide fallback content, for use if (a) the browser did not have the Flash plug-in, or (b) the user has disabled Flash because he/she knew that typical Flash presentations are not accessible (to him/her, or in general). > 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. Well, clearly we disagree here. > 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. Agreed, but that doesn't make the embedder any less responsible for ensuring that the resulting page is accessible. > 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. Also agreed. Philip TAYLOR
Received on Monday, 1 September 2008 16:51:04 UTC