W3C home > Mailing lists > Public > www-style@w3.org > September 2008

Re: Acessibility of <audio> and <video>

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 10 Sep 2008 17:20:26 +0200
Message-ID: <48C7E5BA.1020603@lachy.id.au>
To: Dave Singer <singer@apple.com>
Cc: public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>, www-style@w3.org

Dave Singer wrote:
> At 13:22  +0200 4/09/08, Lachlan Hunt wrote:
>> Dave Singer wrote:
>>> 3.2 Method of selection
>>> We suggest that we add a media query, usable on the audio and video 
>>> elements, which is parameterized by a list of axes and an indication 
>>> of whether the media does, or can, meet the need expressed by that 
>>> axis. The name of the query is TBD; here we use 'accessibility'. An 
>>> example might be:
>>> |accessibility(captions:yes, audio-description:no, 
>>> epilepsy-avoidance:dont-know)|
>> That doesn't seem to fit the syntax of media queries, where each 
>> feature is supposed to be given within parenthesis. e.g.
>> <source ... media="screen and (min-height:240px) and (min-width:320px)">
> right...maybe I misplaced a paren;  I didn't manage to work out how to 
> say it as a MQ etc. while avoiding problem syntax or characters.
> <source ... media="(accessibility captions:yes, audio-description:no, 
> epilepsy-avoidance:dont-know)" />
> ?

No, you would have to have each of the expressions in their own 
parenthesis and drop "accessibility" from it, since it doesn't fit 
syntactically. e.g.

media="(captions: yes) and (audio-description: no) and 
(epilepsy-avoidance: dont-know)"

However, I still don't agree this is the right approach, because they're 
describing properties of the video itself, not the target device.

But before we get into discussing the technical issues with the possible 
solutions, we should try to make sure that we have all the use cases 
problems clearly documented.  I started doing this in the WHATWG wiki, 
where there was already a page dealing with video accessibility.


This also serves as an example of the kind of use cases that others 
should try to provide for other features.  Note how the use cases are 
not merely descriptions of disabilities that people have, but they 
provide examples of what kind of content has been published, who is 
trying to access the content, and specifically how they need or want to 
access it.  The list of potential problems are then derived directly 
from those use case.

Lachlan Hunt - Opera Software
Received on Wednesday, 10 September 2008 15:21:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:39 UTC