Re: unifying alternate content across embedded content element types

Hi Lachlan,

On Jul 26, 2007, at 10:47 PM, Lachlan Hunt wrote:

>
> 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.

We all agree that other content should be made more accessible.  
However, HTML is a pioneer in this area and it also provides simpler  
methods to make content accessible that authors can use with less  
required skill set and expense than with other media. That is not  
something we should throw away.

>
> 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.

That refutation does make sense, because Sander is arguing for  
alternatives and you are suggesting that HTML should not provide  
those alternative (should not try to make up for accessibility  
deficiencies — inherent or otherwise — in other media)

> 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.

You're providing argument that support Sander's contention. If  
YouTube indexes content without searching the video files themselves,  
but rather "other content on the page", then the more apt fallback  
content provided on that page the better the search results.  
Providing a rich fallback content within <video> will lead to better  
search results than a simple one-line "download this file here".

> [...]
>
> 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.

These seem like the types of arguments one might make in a group  
trying to decide what audience are we targeting? What are their  
accessibility needs? How many resources should we devote to that?  
Those questions have almost zero relevance to our current endeavor:  
providing an updated HTML with facilities for authors to use once  
they've made those decisions. We build HTML on top of Unicode  
precisely because it meets many Il8n needs. We add accessibility  
features because those can meet authors needs in a flexible manner.  
Will some decide to simply provide <object> fallback instead of  
making the extra effort to add captioning and audio description to  
their video files? Possibly. Those are practical decisions that  
authors will have to make. Those decisions do not seem all that  
relevant to whether we should provide flexible approaches to meeting  
authors needs.

> 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.

Except there is often overlap in these areas, and the various  
communities surrounding accessibility have often found that overlap  
to be a benefit that creates economies of scale. In other words  
providing facilities in HTML and in HTML conforming UAs for authors  
and users often meets two or more of these needs at the same time.

>> 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.

Again, that should be an option. However, the point is that providing  
fallback for the visually or hearing impaired often overlaps with  
providing fallback for technological barriers. Providing a <video>  
element that supports fallback content within it, can provide authors  
with: 1) fallback when a UA is not HTML5 conforming; 2) fallback when  
a video format, captioning format or CODEC is unsupported; 3)  
fallback when the user has a visual or hearing impairment. Depending  
on the way an author uses the facility it can also succeed or fail on  
one or more off those counts. For example, your example doesn't  
really address (2) or (3), though by addressing those it would also  
address (1). Again, that provides an excellent example of the overlap  
in fallback needs.

>> 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.

To me this is about providing authors with alternative approaches.  
HTML really leads the way in accessibility: particularly in the ease  
of authoring accessible content.

> 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.

It certainly is not our responsibility to address the accessibility  
of other formats. However, it is our responsibility to recognize that  
HTML is a leader in this area. Many formats were not really designed  
from the ground up with accessibility in mind, like HTML. For  
example, PDF is much more focussed on visual fidelity and device  
independence. HTML on the other hand is focussed on semantic fidelity  
and device independence. Making a PDF file accessible undermines many  
of the other goals of PDF. Not so with HTML: accessibility goes hand  
in hand with many of HTML's goals (such as device independent  
semantic fidelity).

>>> 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.


What about <audio> and <video>  then. I really do not understand how  
those additions in HTML5 are all that different than adding  
<picture>. All of those could use <object> equally well if we fixed  
the various implementations  of that element. Yet <video> and <audio>  
are seen as challenging received wisdom, while <picture> is seen as  
breaking backwards compatibility. Again an inconsistent application  
off principles.

Take care,
Rob

Received on Friday, 27 July 2007 05:41:00 UTC