Re: Accessibility of <audio> and <video>

On Wed, Oct 15, 2008 at 5:18 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 14 Oct 2008, Jim Jewett wrote:

>> In an ideal world, the accessibility features would be
>> in the video.

>> In the real world, often they aren't.

> Then the videos aren't accessible. This is a problem,
> that we should try to solve. HTML isn't involved in this
> scenario -- the videos aren't accessible in SVG or
> SMIL or anything else either.

Agreed.  Do you propose to ban even linking to those videos?  If not,
then we need some way to at least ameliorate the problem from the
HTML.

> If we are to assume that the video will be authored
> without accessibility aids, it seems odd not to also
> assume that the HTML will be authored
> without accessibility aids.

The video and the referring web page are often (usually, in my
experience) authored by different people.  We have plenty of evidence
that at least one of those authors will often not worry about
accessibility.  We have no reason to assume which of them that will
be.  Therefore, we need to support accessibility aids from either
document.  For within-video accessibility, it makes sense to delegate
to the video format.  For the HTML page -- we have that
responsibility.

> We don't have a fallback for including a separate audio
> track for the case where the video doesn't have its own
> audio track, or a fallback for including an image's color
> palette for the case where an indexed color image
> doesn't have its own palette, or whatever.

Because none of those affect acessibility; they have the same effects
on everyone, including the author, so the effect is presumably
intentional.

>> FWIW, this is probably a good example of why some
>> accessibility folk get so heated:

>> Everyone agrees that valid markup is best -- but it is
>> settled that HTML5 browsers will not require it.

> But valid markup is still required of authors. There's no
> feature available only to authors who don't write valid
> markup, it's only error handling.

That error handling means that -- in practice -- they do not need to
write valid HTML.  It will appear correct in their own visual browser,
and it will even appear correct in other browsers, because the error
handling is standardized.

We can say that the invalid HTML is wrong, but we are supporting it.

>> Everyone agrees that valid SVG is best, but there were
>> long discussions about which requirements to ignore,
>> in favor of the HTML leniency -- even though existing
>> content does not require it.

> But valid SVG is still to be required of authors. There's no
> feature that is to be available only to authors who don't
> write valid SVG, it's only error handling.

It seemed to me that some of the proposals were about loosening the
syntax, and still considering it valid.  But again, if the error
handling is consistent, then it is supported in practice.

>> Everyone agrees that embedding accessibility
>> information in the original is best -- but existing
>> content does not always do this.  So why is
>> accessibility the only case where the standard
>> suggests "tough -- do it right or not at all"?

> It's the same here. We don't add extra features for
> people doing it the worng way. They're in the wrong,
> and what's left is error handling.

Go ahead and add words saying "This is deprecated, use the video
formats own accessibility aids instead".  But those "errors" are out
there already, and will continue to be out there.  And unless the page
author also controls the video (both legally and technically), there
is no way to do it "right", so the "deprecated" method needs to be
supported as well.

> Accessible video is too important to allow it to be
> left up to some bolt-on fallback features in HTML.
> We have to have features that are embedded right
> at the video resource level, so that users never lose
> these aids even when they save the video files
> separately and reuse them.

The situation today is that those aids are *already* lost because they
were never there.  We can support a workaround (backup accessibility
from HTML) or we can toss out accessibility out in favor of "should".

HTML5 (rightly) hasn't put much stock in "should" anywhere else.

-jJ

Received on Wednesday, 15 October 2008 23:36:50 UTC