Re: unifying alternate content across embedded content element types

Sander Tekelenburg wrote:
> At 09:09 +1000 UTC, on 2007-07-27, Lachlan Hunt wrote:
>> <video src="/movie">
>>    <a href="/movie">Download the video</a>
>> </video>
>>
>> The content of the video element is fallback for those that don't
>> support the video element.  It doesn't make the video itself accessible.
>>   The video should, ideally, be made accessible by providing, for
>> example, captions and audio descriptions embedded in the file itself.
> 
> You've claimed before that that would be ideal, but would you mind explaining
> what exactly would be ideal about it? Because I don't see it.
> 
> I do see that in *some specific cases* it would be ideal. If your hearing is
> bad, or you're in a situation where having the sound loud enough to hear the
> video would bother other people, video with captions would be nicer fallback
> then (marked up) text. But when you can't see, or your browsing environment
> doesn't provide the video's required bandwidth or CPU, or you're an indexing
> bot, downloading the video and reading the captions isn't much of an option.

If I understand you correctly, you're refuting my statement that 
captions/audio descriptions would be ideal the deaf/blind people, on the 
grounds that there are *different* cases for which those solutions 
aren't appropriate!?  If that's right, then you're argument doesn't make 
sense.  Like I said, different needs require different approaches.

But let's consider the indexing bot for a moment.  Sites like YouTube 
seem to provide fairly good search facilities, yet they obviously don't 
search the video files themselves.  Rather, the video's title, 
description and other content on the page fulfils those needs.

The bandwidth issue also has it own solutions.  There are many sites 
that offer lower quality videos with smaller file sizes for users with 
slower connections.  Also, users don't necessarily have to stream the 
video.  It's usually possible to let the video download sufficiently, 
prior to watching it.  For example, I'll sometimes download and watch HD 
movie trailers from Apple's trailer site.

http://apple.com/trailers/

Those files are often well over 100MB, and even with my ADSL connection, 
they won't stream.  But that doesn't stop me downloading them and coming 
back an hour later to watch it when it's done.

There a whole range of other issues that could cause problems for some 
people in the world, such as i18n.  A non-English speaker wouldn't be 
able to understand a video that only provides English dialogue and 
captions.  Again, this issue has its own solution as well, such as 
subtitles in alternative languages.  But even then, it's unrealistic to 
provide subtitles for the hundreds of different languages in the world. 
  There are always going to be practical considerations and some groups 
are inevitably going to be missed.

This is why we should avoid conflating accessibility issues with 
technological barriers, i18n issues, and whatever else.  There is no 
one-size-fits-all solution, and it doesn't help to pretend that one can 
be developed.

> Add to that the authoring burden. Having to provide the same video in 
> different formats, all with their own mechanism to add captions, seems likely 
> more work and more expensive than providing a (marked up) textual alternative.

I didn't say providing multiple formats was an ideal solution, but it 
does happen in reality.  For example, it's quite common to see sites 
offering choices between Windows Media, QuickTime, and Real player for a 
variety of bandwidths.  Sure, ideally, there would be some common, 
widely supported video formats, but that issue out of scope for the HTMLWG.

> Lastly, what guarantee or even strong evidence is there that [1] the authors
> of video formats will in fact provide such fallback mechanisms and [2] web
> publishers will (be able to) make use of those?

What evidence is there to show that such authors will provide fallback 
mechanisms, like a textual alternative for video, in HTML?  You have to 
look at the issues for all mechanisms.  Problems with one solution 
doesn't automatically mean the alternative solution is any better.

You also have to consider whether or not it's the responsibility of the 
HTMLWG to address the accessibility of, and make up for the limitations 
in, every other format.  The issue isn't always black and white, the 
answer isn't always yes.  For example, I don't think it should be the 
role of HTML to patch the accessibility issues with Flash or PDF. 
Accessibility problems with such formats should be resolved within those 
formats, by the groups developing them.

>> If you also wanted to provide an alternative for users that don't
>> support the video format, then that would require a different approach.
>>   Perhaps the video could be provided in multiple formats, or perhaps
>> some kind of textual alternative that describes both the dialog and
>> action in the video.  The textual alternative may also be useful for
>> users who are both deaf and blind, for whom captions and audio
>> descriptions are both ineffective.
> 
> Right. So the textual equivalent is the only one that'll work for all users.

It may work, by some lose definition of "work", but it's far from ideal. 
  I don't think that attempting to address accessibility with a 
one-size-fits-all solution is the best approach.

> Btw, at <http://krijnhoetmer.nl/irc-logs/whatwg/20070701#l-225> you said:
> 
>> I really do not get the whole <picture> idea. It provides nothing more than
>> <object> does
> 
> As explained, what it provides over <object> is that <object> is broken in IE 
> and therefore no option to authors.

That argument was already raised and addressed several times.  <object> 
needs to be fixed anyway, and we're working on that, but replacing a 
broken feature with a completely unsupported feature, and assuming that 
it won't be broken when implemented, is a flawed approach.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Friday, 27 July 2007 03:47:44 UTC