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

[Remco]

On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedt<philipj at opera.com> wrote:
> On Wed, 12 Aug 2009 12:52:38 +0200, Remco <remco47 at gmail.com> wrote:
>
>> On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedt<philipj at opera.com>
>> wrote:
>>>
>>> Before suggesting any changes to the <source> element, make sure you have
>>> read
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm
>>>
>>> Put simply, the handling of <source> is already quite complex,
>>> overloading
>>> it with completely different meanings is not a good idea. <video> won't
>>> handle "text/html" as a source, but if you want different media files for
>>> different audiences I suggest experimenting with <source media>.
>>
>> <source media> doesn't do anything useful for my case. It can't load
>> textual data. Also, if the resources are unavailable, there will be
>> nothing to see, since all resources are off-page. It also doesn't work
>> for iframe, object, embed or img.
>>
>> Is it really the idea that the only way you're going to have
>> alternative textual content, is to Build It Yourself? You have to
>> abuse <details> or a hidden <div> with some Javascript to build a
>> construction that has alternative content in case the
>> video/audio/iframe/object/embed is not available or desirable. If you
>> want it to be semantically accessible, you even have to build another
>> layer on top of that, in the form of ARIA attributes.
>
> No, in the long term we want native captions/subtitle support in the
> browsers. See
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html
> and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html

OK, that's awesome. I mean, really! That is on par with DVD
functionality. But that's not exactly my case. It involves subtitling
the video. The format has to be learned, and time has to be spent on a
video. If a web author has no intention of doing so, but wants to give
a short textual alternative and be done with it, he is not able to do
that.

>> Nobody will do that. Even the <source> solution is harder, maybe too
>> hard, to use than the alt="" solution. It requires authors to create
>> additional elements or pages to house the alternative content. Since
>> accessibility is often an afterthought, about the most an author will
>> be willing to do, is filling in an alt attribute.
>
> What do you suggest a browser do with the alt attribute? The resource
> selection algorithm never ends until a suitable source is found, so when
> should the alt text be displayed? By requiring anything at all, browsers
> can't do things like display a box with a direct download link, suggestion
> to install a specific codec, etc. If nothing at all is required of user
> agents for the alt attribute, then I have no opinion (but then I expect no
> one would use it either).

Well, I would suggest that the browser displays the text when no
desirable resource is available. In the case of network problems, no
resource at all is available. In the case of a textual browser (or a
"Disable Media" button), all videos are undesirable. You can still
show a download link or a codec suggestion, but you can display the
alt text below it, for the people who don't really care about a video,
or people who know the network connection won't be back for some time,
or people who can't or won't install the codec.

I must admit that I don't understand the media selection algorithm.
You say that it never ends. How does that work? The browser keeps
looping through the source elements until one becomes desirable and
available? How does that give browsers the opportunity to display a
download link or a codec suggestion? How should textual browsers
handle that?

If videos are desirable and available, but text is also desirable,
then the alt text could be displayed/spoken/etc when you tab onto it,
as Silvia Pfeiffer proposed in a previous email.

Remco