[whatwg] Alt attribute for <video> and <audio>

[Remco]

On Tue, Aug 11, 2009 at 8:20 PM, Charles McCathieNevile<chaals at opera.com> wrote:
> On 10/08/2009 04:05, Remco wrote:
>> But Elephants Dream may not be a good example for a video where an alt
>> text would be useful. It's simply too complicated to replace with
>> alternative text. But if you have a short video that explains
>> something on Wikipedia, it would be tremendously helpful if the alt
>> text would convey the same meaning. A video of a ball falling to show
>> what gravity is, could have the alt text: "A ball accelerates as it
>> moves down. Next to the ball's trajectory, a speedometer increases
>> with 9.8 m/s per second.".
>
> If you ant to provide an alternative, then I suggest that is not a good one.
> It is a description of the video, rather than a replacement.
>
> An alternative is something more like
>
> "As a ball falls, every second it goes 9.8m/s faster than it was going a
> second before, because gravity makes it accelerate. In practice, effects
> such as "drag" (wind resistance) will affect the actual speed - and the
> value of 9.8 is specific to the average sea-level of earth - it depends on
> the mass of the earth and the ball."

Actually, you have provided here not only a description of the video,
but also an explanation of why things happen. The video shows a ball
falling down and a speedometer increasing with 9.8 m/s per second.
Nothing more. My text is simply a replacement for the video. It tells
precisely what happens, and nothing more. Of course, you need to see
the video (or the replacement text) in context of the Wikipedia
article. Without context, neither alternatives make sense.

>> One advantage of this is that the alternative content is now by
>> default always visible (or can be made visible in the case of
>> <details>). That makes it much more useful for normal use cases (no
>> network problems or disabled audience), which means it would be
>> provided a lot more. This is a lot better than the current situation
>> with alt.
>>
>> The question now is: why would we need both <figure> and aria-describedby?
>
> Because many designers will not put sufficiently complete text explanations
> of everything in the ordinary flow of a document. This is actually a
> valuable accessibility practice - the large number of people who have
> difficulty reading can often find that their ability to use content is
> significantly reduced by the presence of large blocks of text. This is
> something that most usability engineers and communication experts understand
> instinctively, actually.

Ah yes, you're right.

> So we need some way that allows for more than one presentation scenario.
> Either we ask people to make multiple pages (something that is well-known to
> suffer from the "out of sight out of mind" problem, or we provide ways to
> manage more information in a single page (which also suffers from the
> problem, but it is believed less so. I don't know how many careful studies
> have been done of this, if any).

In general I think ARIA needs to be better integrated with HTML. Right
now it's just a bunch of additional attributes that don't have a
functional purpose for Normal People (TM). It's strictly a foreign
extension to HTML that is only really useful for people that care
about accessibility (say, 1% of the web author population). Most
attributes even have the 'aria' prefix, which tells you that you need
to learn some standard for disabled people before you can use this.

It would be nice if all ARIA roles could be made into first-class HTML
elements. That way, I only have to build my constructs once, and it's
accessible implicitly. At the moment, some roles have native HTML
counterparts, while others do not.

The above has been discussed before, so I'll just add my voice to the
choir: the ideas of ARIA desperately need to be integrated into HTML,
because as it stands, it will *not* be used.

As a small part of integrating the ideas of ARIA into existing HTML 5,
I just got an idea for a better solution for replacement content for
video and audio: <source>.

The source element is used to provide media elements with multiple
sources. What if one of those sources could be an element on the page
itself? The text is just another source which could link off-page, or
on-page.

<video>
<source type="video/theora" src="primary-content.ogg">
<source type="text/html" src="#alternate-content">
<source type="text/html" src="alternate-content.html">
</video>

Alternative content in <source> which comes from an element on the
same page is an extension to what you already know, and it doesn't
require you to know about a special accessibility part of HTML.

In addition: currently, <source> is only used for <audio> and <video>,
but why not extend it to any external element?

<iframe src="primary-content.html"><!-- legacy -->
<source type="text/html" src="primary-content.html">
<source type="text/html" src="#alternate-content">
<source type="text/html" src="alternate-content.html">
</iframe>

<object><source ... ><source ... ></object>
<embed><source ... ><source ... ></embed>
<img><source ... ><source ... ></img>

That last one may be problematic, since img-elements have
traditionally never had a closing tag. I don't know how browsers will
react to something like that. Maybe it would be better to have alt=
and longdesc= remain for the img-element, and give longdesc the
aria-describedby functionality (it could link to an element on the
same page) in addition to the original meaning.

Remco