Re: unifying alternate content across embedded content element types

At 13:47 +1000 UTC, on 2007-07-27, Lachlan Hunt wrote:

> Sander Tekelenburg wrote:
>> At 09:09 +1000 UTC, on 2007-07-27, Lachlan Hunt wrote:

[....]

>> 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!?

Huh? No! Please reread. I'm saying that, while a file format-specific
accessbility feature may *in certain cases* be ideal, it's not a general
solution (because it solves only that *one specific situation*). You OTOH
said that "The video should, ideally, be made accessible by providing, for
example, captions and audio descriptions embedded in the file itself."
without specifying why that would be ideal or for whom that would be ideal. I
was, and still am, trying to understand what you mean with "ideal", why you
think that's ideal, and why you think that could ever actually work in
practice.

> [...] Like I said, different needs require different approaches.

We cannot expect individual authors to know all users' different needs and
how to cater for them. The only realistic option is to provide a spec that
allows people to author for one single Web for all users.

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

Wouldn't the existence of marked up equivalent text allow for much better
indexing?

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

{shrug} There are many sites that provide one size, one format only. (Which
suggests it is perhaps too difficult or too expensive to provide such
equivalents.)

> Also, users don't necessarily have to stream the
> video.  It's usually possible to let the video download sufficiently,
> prior to watching it.

Sure, but AFAIK millions are still accessing the Web over slow (analog) modem
connections and/or are charged for their traffic. (My impression is that it's
quite common for ADSL connections to be limited to 1GB/month download for
instance.)  For many users a textual equivalent may well be the only
realistic option.

> For example, I'll sometimes download and watch HD
> movie trailers from Apple's trailer site.

Sure, me too. It' fun. But our luxury isn't representative of the world's.

[...]

> There a whole range of other issues that could cause problems for some
> people in the world, such as i18n.

Unicode and HTTP's content negotiation already handle i18n.

[...]

> [...] There is no
> one-size-fits-all solution, and it doesn't help to pretend that one can
> be developed.

I really want to understand your position. I'm well aware that I don't know
everything. But simply saying "this is how it is" doesn't help.

FWIW, my gut feeling is that we actually agree, but are just loooking at the
same thing from a different angle. You're saying that for specific cases,
specific solutions are the ideal. I'm saying that while I agree with that, it
isn't realistic to expect an accessible Web with that approach -- that HTML
needs to provide a single general 'fallback' mechanism consisting of marked
up text. Yes, I'm well aware that for certain specific cases such fallback is
not the richest possible fallback, and in that sense not 'ideal'. But it is
the only approach that can possibly 'work' for all situations *and* it still
leaves all the room in the world for richer equivalents (such as captioned
video).

[...]

> it's quite common to see sites
> offering choices between Windows Media, QuickTime, and Real player for a
> variety of bandwidths.

My impression is that only a few sites, with relatively big budgets, do that.

[...]

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

Please, could you answer the question? Responding with another question is a
nice technique in debates that are about winning, but it's not going to help
us understand each other.

In the mean time I'll (re)answer your question anyway: it's not in the first
place a matter of whether they actually will, but of *if they will*, then
which sort of equivalent will be the easiest, most affordable equivalent that
authors can provide that will be useful to the most users. My bet is on
marked up text.

[...]

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

When served through <object>, HTML already does provide for the possibility
of a marked up textual equivalent. What's wrong with that? It leaves Adobe
all the room in the world to improve Flash and PDF, but until they do, if
ever, we at least have richly marked up textual equivalents. What is wrong
with that?

> Accessibility problems with such formats should be resolved within those
> formats, by the groups developing them.

You're not saying why, nor why it is likely that that will actually work in
practice.

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

What's not ideal about it?

[... <picture>]

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

That's great news. I wasn't aware of that. Looking forward to seeing the
results.

> , but replacing a
> broken feature with a completely unsupported feature, and assuming that
> it won't be broken when implemented, is a flawed approach.

Honestly, I find it extremely difficult to understand what such statements
("broken when implemented") are supposed to mean. Do you mean that a first
implementation will have bugs? If not, what? And why does that not apply to
all the other new elements and attributes in HTML5? What makes <picture>
different in this respect?

Btw, I don't know if you skipped over this intentionally or not, but I'd
still really appreciate a response to this bit, because I truly don't
understand what is meant with "has no browser support":

[about <picture>]

>> , and has absolutely no browser support
>
> I heard that argument before and would really appreciate an explanation -- I
> honestly don't see how it can be considered an argument. How does "<picture>
> has no browser support" mean anything? "<p>" had no browser support either,
> until browsers started supporting it. Browsers have no <canvas> support until
> they start supporting it.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Friday, 27 July 2007 06:35:33 UTC