[whatwg] accessibility management for timed media elements, proposal

Sat Jun 9 08:35:01 PDT 2007

Dave Singer wrote:
> we promised to get back to the whatwg with a proposal for a way to 
> handle accessibility for timed media, and here it is.  sorry it took a 
> while...

Three cheers for Apple for trying to tackle some of the accessibility 
issues around video content! :) Without trying to assess whether CSS 
media queries are the best approach generally, here's three particular 
issues I wanted to raise:

1. Property values

I honestly don't think the property values are well-named. "either" is 
confusing and vague; "dont-want" is a misspelled colloquialism. How 
about one of the following possibilities:

captions: wanted
captions: unwanted
captions: no-preference

(This seems more natural to me than the original proposal.)

/or/

captions: prefer
captions: prefer-not
captions: no-preference

(Has the consistency of using the same word as the basis for each value. 
OTOH "prefer-not" and "no-preference" may be confusing if your English 
isn't that good.)

/or/

captions: desired
captions: undesired
captions: no-preference

("desire" has the minor advantages of being in Ogden's basic English 
word list and being common to Romance languages thanks to a Latin root. 
OTOH it's slightly longer.)

2. Conflict resolution

The proposal does not describe how conflicts such as the following would 
be resolved:

User specifies:

captions: want
high-contrast-video: want

Author codes:

Because style rules cascade, this sort of conflict doesn't matter when 
media queries are applied to styles. But you can only view one video source.

3. (Even more) special requirements

The suggested list of media features is (self-confessedly) not 
exhaustive. Here's some things that seem to be missing:

a) I should think sign-language interpretation needs to be in there.

sign-interpretation: want | dont-want | either (default: want)

Unless we want to treat sign interpretation as a special form of 
subtitling. How is subtitling in various languages to be handled?

b) Would full descriptive transcriptions (e.g. for the deafblind) fit 
into this media feature-based scheme or not?

transcription: want | dont-want | either (default: either)

c) How about screening out visual content dangerous to those with 
photosensitive epilepsy, an problem that has just made headlines in the UK:

http://news.bbc.co.uk/2/hi/uk_news/england/london/6724245.stm

Perhaps:

max-flashes-per-second: <integer> | any (default: 3)

Where the UA must not show visual content if the user is selecting for a 
lower number of flashes per second. By default UAs should be configured 
not to display content which breaches safety levels; the default value 
should be 3 /not/ any.

Compare:

http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G19

d) Facilitating people with cognitive disabilities within a media query 
framework is trickier. Some might prefer content which has been stripped 
down to simple essentials. Some might prefer content which has extra 
explanations. Some might benefit from a media query based on reading 
level. Compare the discussion of assessing readability levels at:

http://juicystudio.com/services/readability.php

reading-level: <integer> | basic | average | complex | any (default: any)

Where the integer would be how many years of schooling it would take an 
average person to understand the content: basic could be (say) 9, 
average could be 12, and complex could be 17 (post-graduate).

This wouldn't be easily testable, but it might be useful nevertheless.

Postscript: This isn't an accessibility issue but /if/ media queries are 
adopted as a mechanism for serving up the best content for a person's 
abilities, I wonder if they could also be used to enhance parental 
control systems using queries based on PICS:

http://www.w3.org/PICS/

So for example, one <source> might have a music video featuring 
uncensored swearing, and another <source> might have the same video with 
the swearing beeped out.

--
Benjamin Hawkes-Lewis