[whatwg] accessibility management for timed media elements, proposal

[Dave Singer]

At 0:02  -0400 10/06/07, Brian Campbell wrote:
>On Jun 9, 2007, at 5:26 PM, Dave Singer wrote:
>
>>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?
>
>Almost no sign languages are related to the spoken language in the 
>same region any more than any two spoken languages are related to 
>each other.

OK, but are they often, sometimes, or never geographically 
co-located?  i.e. if there are N spoken languages in the world and M 
sign languages, do we really have MxN possibilities of what a given 
sign-language-capable person can do?

>Sign languages are full-fledged languages in their own right, not 
>signed transliterations of spoken language (though they do 
>frequently have an alphabet system for signing words and names from 
>spoken languages). So, American Sign Language is not actually 
>related to English any more than other languages spoken in America 
>are (like Cherokee or Spanish).
>
>The situation with the ISO 639-2 codes is unfortunate, because there 
>is only a single code for all sign languages, sgn. It appears that 
>the solution is to add extensions specifying the actual language, 
>such as sgn-US or sgn-UK. There's more information available here: 
><http://www.evertype.com/standards/iso639/sgn.html>

That is truly unfortunate, however, I guess it's not in scope for 
HTML to solve.

At 12:05  +0100 10/06/07, Benjamin Hawkes-Lewis wrote:
>>>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.
>
>But if UAs can apply accessibility preferences to a catch-all <source>
>listed last, then what's the advantage of creating multiple <source>
>elements in the first place?

There are two common cases to consider:
a) the accessibility option is 'burned in' to the media (e.g. burned 
in captions);  you then need to select the right one
b) the media is adaptable (e.g. tracks that can be enabled in a QT 
movie);  you then need to select it and adapt it.

It may be that there isn't an accessible version of the movie 
suitable for your accessibility needs (it does hapen sometimes -:(). 
It might be prudent to author the page so that such users get to see 
something.

>Current container formats can
>include captions and audio descriptions. So is the problem we're trying
>to solve that container formats don't contain provision for alternate
>visual versions (high contrast and not high contrast)? Or are we 
>trying to cut down on bandwidth wastage by providing videos 
>containing only the information the end-user wants?

Both, I think.

>
>>>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.
>
>The lang attribute specifies "the primary language for the element's 
>contents and for any of the element's attributes that contain text", 
>not the referenced resource. hreflang "gives the language of the 
>linked resource" as a single "valid RFC 3066 language code." So we'd 
>need a new attribute or to change the content model of hreflang to 
>explicitly specify the separate multiple languages of a resource.
>
>http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#the-lang
>
>http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#hreflang3
>
>I note in passing that these attributes should be updated to use RFC 
>4646 not RFC 3066 as per:
>
>http://www.w3.org/TR/i18n-html-tech-lang/#ri20030112.224623362

This could quickly become unworkable, and I feel that perhaps it 
would be best to drop into a composition language such as SMIL, where 
one can then explicitly ask for a 'par' of two selections, one 
selecting the audio (by spoken language) and one the signing (by sign 
language).

>
>>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?
>
>Brian Campbell has eloquently answered some of these questions.
>
>The reason I was thinking of using a CSS property was that signed 
>interpretation is not the same as signing featured in the original 
>video. But it's true that information about what sign languages are 
>available is important, so a CSS property alone wouldn't solve the 
>problem. Maybe we need new attributes to crack this nut:
>
><source contentlangs="en,sgn-en" 
>captionlangs="sgn-en-sgnw,fr,de,it,sgn" dubbinglangs="fr" 
>subtitlelangs="de,it" 
>signedinterpretationlangs="sgn-en,sgn-fr,sgn-de,sgn-it" ...>
>
>This would indicate that the main video content features people 
>talking in English and people signing in English; the video is 
>captioned in English, French, German, Italian, and their SignWriting 
>analogues (American Sign Language in the case of English), dubbed in 
>French, subtitled in German and Italian, and provided with signed 
>interpretation in American, French, German and Italian Sign 
>Languages.
>
>Granted it's a sledgehammer,

It really does seem very heavy.  I guess a meta-goal here was to try 
to make a system that was simple and comprehensible enough that a 
reasonable number of web authors would use it.

>>
>>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
>>-:)
>
>Why?

simplicity, comprehensibility, both of which lead to likelihood of 
adoption.  Also, the matching process doesn't need to know anything 
about what the axes mean.  If we allow quantitative measures, then 
the user would have to be able to express "less than X", "greater 
than Y", or maybe even "between X and Y", and content authors would 
have to know how to measure, rather than simply knowing how to tag.



-- 
David Singer
Apple/QuickTime