Re: Accessibility of <audio> and <video>

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

SVG and SMIL have switches to provide alternative formats including
text. One can switch between anything, video, audio, text, image,
animation, graphics, whatever might be appropriate to replace the
inaccessible format.
And SVG has title, description and metadata for any element to
provide additional (structured) information. This can always help,
if there is a problem in understanding the purpose of a fragment,
accessible or not.
For elements having xlink:href, there are more XLink attributes available
to inform about the xlink:role or xlink:arcrole.
If the author wants to provide meta information or accessibility information
in SVG, there are multiple possiblities to do this.
Maybe HTML should at least have a meta element for any element as a
container for structured meta information or alternatively elements 
to structure the meta information in the head and the ability to point
to fragments to identify the target of the structured meta information.
This could already help authors to provide useful descriptions for
problematic content, for whatever reason the content is considered to
be problematic to understand.

Using the SMIL Metainformation module and RDF, SMIL provides similar
possibilities too. 

DocBook for example has several meta information elements, for
multimedia objects it provides several possibilities to get an
accessible alternative.

This indicates already, that several formats have no problem to
give the author at least the chance to provide different alternatives 
including text. The technique in HTML seems to be a 
little bit old fashioned currently. And those formats give the
chance to fix the accessibility problem within such a format
without moving the solution necessarily into the referenced 
document.

Of course, instead of using HTML:img, HTML5:audio, HTML5:video,
HTML5:canvas etc authors can simply always use HTML:object 
referencíng a document of the formats SVG, SMIL, DocBook etc 
to get access to an advanced method to provide alternatives and 
meta information, or they can use a compound document - 
but as far as I understand, this is not really the intended concept 
of HTML5? Obviously such an approach increases the requirements 
for a user-agent to provide the information at all, because more 
formats are involved than necessary for this purpose.

Received on Wednesday, 15 October 2008 12:33:20 UTC