Re: Accessibility of <audio> and <video>

I am a little confused, does "here is a video with no native
accessibility data because the author doesn't know/care about
accessibility or [insert captions etc here]" = error handing in the
current spec? Do we then call the addition of accessibility meta data,
in its multitude of forms, error handling?  If so, for the purposes of
this post and its context I will define error handing as "adding
accessibility stuff using the host language for a rich media element in
HTML 5".

Authors should, of course, provide as much native/embedded etc
accessibility data in the video files that they create from the get go.
As Patrick pointed out this is often not the case in the real world as
the same rational applies to regular web authors, they /should/ write
good semantic valid code, provide for multiple user requirements and so
on but they don't. This brings me to:

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.

Ian said:
> 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.

Yes, so then the question arises "Should the host language for that
content be able to provide sufficient error handing?" I would say Yes,
otherwise we may as well use HTML 4, if the new host language does not
offer any more advanced capabilities that acting as a shell for the rich
media content. I am not saying this is the case but just offering it for
the sake of illustration.

On Tue, 14 Oct 2008, Jim Jewett wrote:
>> By all means encourage authors to put the accessibility information 
>> > within the video.  But there needs to be a fallback for cases where that 
>> > doesn't happen.

+1

Ian said:
> I don't see why. 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

Is this not exactly the kind of thing the host language /should/ be able
to do? In principle are we not talking about the same thing or maybe
there is a disconnect in terminology? There should be fallback
repair/error handing capability within the host markup language that
allows the author to add missing/complimentary accessibility metadata
that is not embedded or native within the video file and so on.

It seems to me this is a good opportunity by to develop this capability
in the host markup language, to support any content (I mean repair/add
accessibility data) in order to make up for that which is missing in the
<video> or other rich media. Giving the markup language the greatest
scope to support accessibility at the markup level in order to repair
the video due to author ignorance/indifference is the way to go. FWIW I
don't even know if HTML5 is just a markup language anymore.. or should
HTML 5, a declarative markup language (sic) move from that definition
and redefine itself in order to /explicitly/ be able to do such things?

Cheers

Josh

Received on Thursday, 16 October 2008 13:03:55 UTC