[whatwg] accessibility management for timed media elements, proposal

At 16:35  +0100 9/06/07, Benjamin Hawkes-Lewis wrote:
>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! :)

Many thanks for all your helpful comments!

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



We struggled with this also;  suggestions are welcome.

>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.)

nice (in my personal opinion).

>
>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:
>
><video ... >
>   <source media="all and (captions: want;high-contrast-video: 
>dont-want)" ... />
>   <source media="all and (captions: dont-want;high-contrast-video: 
>want)" ... />
></video>

There is no suitable source here;  it's best to have something (late) 
in the list which is less restrictive.

>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?

I think we assume that a language attribute can also be specified, as today.

I have to confess I saw the BBC story about sign-language soon after 
sending this round internally.  But I need to do some study on the 
naming of sign languages and whether they have ISO codes.  Is it true 
that if I say that the human language is ISO 639-2 code XXX, and that 
it's signed, there is only one choice for what the sign language is 
(I don't think so -- isn't american sign language different from 
british)?  Alternatively, are there ISO or IETF codes for sign 
languages themselves?

>
>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)

how are these presented to a deafblind user?

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

I think we'd prefer not to get into quantitative measures here, but a 
boolean "this program is unsuitable for those prone to epilepsy 
induced by flashing lights" might make sense.  epilepsy: dont-want -:)


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

Yes, this isn't testable, and is quantitative.

>
>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


-- 
David Singer
Apple/QuickTime

Received on Saturday, 9 June 2007 14:26:09 UTC