- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 10 Jun 2007 12:05:55 +0100
Dave Singer wrote: > At 16:35 +0100 9/06/07, Benjamin Hawkes-Lewis wrote: [snip] >> 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? 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? >> 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 > 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, but it does provide the fine-grained linguistic information we need. It would also seemingly remove the need for putting a caption media query on <source>. While this markup looks complicated, most videos currently on the web could be marked up like: <source hreflang="en" ...> as all they provide is a single-language spoken track. <digression> I should add a little note about "sgn-en-sgnw". The IANA language tag registry includes the following entry: > Type: script > Subtag: Sgnw > Description: SignWriting > Added: 2006-10-17 http://www.iana.org/assignments/language-subtag-registry One might want to omit the sgnw subtag on the basis that other sign language transliterations are academic not everyday (just as one omits the latn subtag for en, fr, and so on). However, those who work on such things have yet to come up with an entirely settled formulation. See this thread on the IETF languages mailing list: http://www.alvestrand.no/pipermail/ietf-languages/2006-October/005126.html Meanwhile, people are already creating SignWriting captions: http://www.webcitation.org/5PUMLS0mp </digression> >> 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? Depends. I think the ideal would be to have transcriptions inside a container format, so that /everyone/ could access them and so that deafbind people who still have some sight can see some of the video. The transcriptions could be dispatched to a braille display. And, yeah, with my sledgehammer system that would necessitate yet another language attribute to indicate what languages transcriptions are provided in. The crudest way of doing this would be to provide transcriptions of audio descriptions to supplement the captions. I believe one can do that with SMIL; I don't know what the situation with other container formats or player UIs is however. Alternatively and suboptimally: <source src="mytranscription.html" hreflang="en" type="text/html" media="all and (transcription:desired)> (Here I'm leaning towards the ideal of catering to all comers with a single container. But sometimes end-users prefer a simple format, e.g. some PDF haters prefer to be given a version in plain text. This tells you more about broken authoring practices and UAs, and about the digital divide between broadband and dialup, than about intrinsic problems with PDF however. Still, if it's possible to provide plain text and plain HTML versions of whatever content you're producing, that's a good idea as a supplement, not just a fallback.) >> 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 > -:) Why? The reason I suggested a quantitive measure was to ensure that encoded information remains relevant even as our medical understanding of the condition changes. WCAG 1.0 stipulated that 4 flashes per second would be dangerous, but WCAG 2.0 stipulates that more than 3 flashes per second would be dangerous: http://www.w3.org/TR/WAI-WEBCONTENT/#tech-avoid-flicker http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G19 So 3.1 flashes would pass WCAG 1.0 but flunk WCAG 2.0. (Thinking about it, this probably indicates the value should be decimal not integer.) I can see there's an ease-of-use issue for authors who know their content contains lots of flashes but haven't actually tested it to find out the flash rate. But if UAs default to 3 as I emphasized they /should/ do, such authors can use the "any" value to avoid having to quantify the number of flashes. If in the future we decide 2 flashes should be the threshold or add further criteria, contemporary UAs could be reconfigured and future UAs could be revised, but the content would go on working. >> 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. For verbal content, it /is/ testable (otherwise WCAG 2.0 would not include it). The Juicy Studio page I referenced included tools to test it with various formulae. Many of these formulae are good enough for governmental use. For example, the US government tends to test documents for readability with Flesch-Kincaid: http://en.wikipedia.org/wiki/Flesch-Kincaid_Readability_Test The uneasiness comes from the fact that WCAG 2.0 does not stipulate precisely which formula(e) to use for testing. See: http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#meaning-supplements I assume that's because: 1) The WCAG guideline needs to continue to be relevant even as formulae improve. 2) Different languages need different formulae, so if they were to mandate a solution they'd have to list a different solution for each language. Here's one for Japanese, for example: http://www.utexas.edu/research/accessibility/resource/readability/manual/formulas-English.html#jap My guess is that /any/ of these readability indices would be good enough for our purposes in practice. We don't need the same reproducibility here as we do when it comes to not triggering epileptic fits! -- Benjamin Hawkes-Lewis
Received on Sunday, 10 June 2007 04:05:55 UTC