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
