- From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
- Date: Sat, 31 Oct 1998 21:10:32 -0800
- To: "Taylor-Made" <taymade@netnitco.net>
- Cc: <w3c-wai-ig@w3.org>
At 08:13 a.m. 10/31/98 -0600, Taylor-Made wrote: >Here is a question that my girlfriend asked me: How do I put >a video on my page so that it will be accessible. I told her >I didn't know as I would never use one. But the person she >is doing a page for wants one. I told her that it could make >her site un-accessible if it didn't work right and that it >will not work on all browsers. (As I know nothing about putting >videos on a page, I hope this information was correct.) My >question for this listserv is: >Is there a way to put a video on a page so that it will be >accessible? >I thank you for your time and consideration on this matter. Hi, Joyce, this falls under two different categories of "accessibility considerations". The first is "media types that aren't supported by all user agents", and the second is "media types that can't be used by all people". The strategies for dealing with them are similar, luckily. (The difference between the two types is that if someone is deaf, but using MSIE 4, their browser may very well support audio and audiovisual media, but they can't take advantage of that.) The best (and likely, only) solution to deal with this in an across-the-board manner is to make all information contained within the multimedia clip accessible at the lowest common denominator level -- which in this case means HTML-enhanced text form. The basic principle is that the _same_ content should be provided in a _non-inaccessible_ (or, call it "accessible") manner -- this content needs to be provided in addition to the inaccessible content. It's a matter of style whether or not this needs to be a case of "offering both" or "trying to identify what the user needs and provide only that". Here's what I'd do, if I were in her shoes: I'd create an HTML-formatted, text-based transcript that includes info on the visual changes seen on the screen, in light detail. In addition, I'd choose specific critical images -- changes from one scene to another -- and provide screen captures as visual images. Those images would have LONGDESC/D-link descriptions to further expand on what's visually displayed at that time. Embedding captioning and other meta-content into the multi- media file as well is a Good Thing to do, but in my opinion, it doesn't reach down low enough to include everyone, and since video captions aren't my forte, I would probably not include that. :) If I had time, though, it would be good -- the more granular your level of support for varying capabilities, the easier it is for someone to use it. Of course, the stock answer would be that you should use SMIL to synchronize the whole thing. ;) Nothing wrong with that answer, mind you. -- Kynn Bartlett <kynn@idyllmtn.com> http://www.idyllmtn.com/~kynn/ Chief Technologist & Co-Owner, Idyll Mountain Internet; Fullerton, California Enroll now for my online stylesheets (CSS) class! http://www.hwg.org/classes/ The voice of the future? http://www.hwg.org/opcenter/w3c/voicebrowsers.html
Received on Sunday, 1 November 1998 00:14:54 UTC