RE: Acessibility of <audio> and <video>

> -----Original Message-----
> From: Leif Halvard Silli [mailto:lhs@malform.no]
> Sent: Monday, September 01, 2008 4:23 PM
> To: 'HTML WG'
> Subject: Re: Acessibility of <audio> and <video>
> 
> Justin James 2008-09-01 19.42:
> 
> > 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.
> 
> Add to that that movie formats are *very* often used for
> displaying photos. Plus the fact the <video> elment itself has a
> poster image to be displayed before the video is started.

Yes, movies often do display still images (or a series of still images), which could be done with non-movie formats which would require accessibility.

> > 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. [...]
> 
> 
> Hear hear! Well, actually, if we can avoid @alt and @longdesc, and
> instead allow textuall fallback <element>inside the element</>,
> then that would be better.

Sure, that makes sense, especially if it uses a "toggle" akin to <noframes>, where it is a block element that does not display the content if the ability to show the video is there.

It can even work on <img>, too. Whatever happens, I believe that it is important that it be applied identically to at least the following elements:

* img
* video
* audio
* object

Consistency goes a long way towards adoption. :)

Lachlan in his response to you has stated that getting HTML authors to write meaningful information for those with accessibility needs here will be an uphill battle (as <noframes> is indeed a good example). But honestly, getting HTML authors to put any kind of accessibility-useful information in documents is an uphill battle, so what else is new? At least this way, we provide the hooks for it, and maybe make at least 1 textual representation mandatory at all times.

> > 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?
> 
> Is it because of the "not getting in the way" side that you
> propose e.g. @longdesc over some variant of <video>fallback</video>?

Nope. I simply didn't think of putting anything into the element itself. Why? Well, for me (and this is *strictly* personal opinion), anything that smacks of metadata or something that it not critical to the display is an attribute of an element, not content. That's just my personal opinion, I know many fights get started on the "attribute or element?" question, but because of my personal tendencies, it rarely even occurs to me to think something like this would be content.

And yes, I am a big believer in void elements as well. :)

J.Ja

Received on Tuesday, 2 September 2008 04:49:40 UTC