- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 24 Aug 2009 23:46:12 +0000 (UTC)
On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: > On Fri, Aug 14, 2009 at 9:13 PM, Ian Hickson<ian at hixie.ch> wrote: > > On Mon, 10 Aug 2009, Remco wrote: > >> > >> Shouldn't <video>s and <audio>s (and maybe <object>s too?) also have > >> an alt attribute? A quick Google search tells me this has not been > >> discussed before. > > > > For users who can use audio but not video, authors should either > > provide audio descriptions in the video file as alternative tracks, or > > supplemental material provided in links available to everyone near the > > video. > > > > For users who can use video but not audio, authors should provide > > subtitles, captions, or transcripts either in the video or audio file > > as supplemental tracks, or in supplemental materials available to > > everyone in links near the video. > > > > For users who can use neither video nor audio, supplemental materials > > are likely the best thing for an author to provide, again, in links > > visible to all. > > > > For users of legacy UAs that don't support these features, > > feature-rich alternatives such as plugins can be provided as fallback > > content for <video> and <audio>. > > > > Captions and subtitles can be included either directly in the media > > file, or scripts can manually support external resources using the cue > > range API. Going forward, we will probably also support dedicated > > formats that UAs can merge with the video to handle showing external > > subtitles natively. > > > > I don't see a need for an alt="" attribute here. What problem would it > > solve that is not solved by the above solutions? > > There is only one thing I can think about that an "alt" attribute could > provide that nothing else does: as a blind user tabs onto a video > element, the "alt" attribute's content could be read out and briefly > describe what is visible in the poster image - or alternatively give a > brief summary of the video. This is useful for all those cases where no > surrounding text is given for whatever reason. Where a surrounding text > is given, such as the video title and description, such text is likely > not necessary. It seems that ARIA attributes, the title="" attribute, <figure><legend>, and just regular UA defaults (e.g. announcing that you're on a video element) are sufficient. On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: > On Fri, Aug 14, 2009 at 11:09 PM, Henri Sivonen<hsivonen at iki.fi> wrote: > > > > I believe aria-label addresses this. > > Excellent. Then I haven't seen a good argument to add it. Let's not. On Fri, 14 Aug 2009, Remco wrote: > > Yes, I think that covers it. This also covers the most important, but > apparently always ignored case: authors who don't have time for > accessibility. A significant portion of web authors will not provide > subtitles for every published video. Nor will they provide links to a > transcript. Even if they care about accessibility, it's just not > economically viable to do it. The best you can hope for is a sentence or > two explaining what the video does. > > This also covers other non-text elements: <iframe>, <embed>, <object>. > > The only thing left is ARIA's integration with HTML. Have you had > success with your draft? http://hsivonen.iki.fi/aria-html5/ I see you > only had one reply to your first announcement. Will the remaining ARIA > attributes be an explicit part of HTML? Will the "aria-" prefix be > removed? ARIA is now integrated in HTML5. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 24 August 2009 16:46:12 UTC