Re: [whatwg] accessibility management for timed media elements, proposal

[Brian Campbell]

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

Re: [whatwg] accessibility management for timed media elements, proposal

[Dave Singer]

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:


  
  




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

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Michel Fortin]

Le 2007-06-09 à 5:26, Anne van Kesteren a écrit :

On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:
I'd agree they're mostly useless in a browser context, but when  
reading HTML with the intent of reserializing it later, preserving  
the whitespace around the document type declaration, the comments  
and the root element can be beneficial for the readability of the  
final output. I'd keep them there, just like XML does.


I don't think XML does that, actually.


I've tested by dumping a tree made with PHP 5's XML parser (libxml2)  
before adding XML to my argument. Now, if I look at the XML spec  
under [2.10 Whitespace Handling][1]:


"An XML processor MUST always pass all characters in a document that  
are not markup through to the application. A validating XML processor  
MUST also inform the application which of these characters constitute  
white space appearing in element content."


To me, "all characters in a document" also includes direct children  
of the document node. But perhaps I'm missing something.


 [1]: http://www.w3.org/TR/REC-xml/#sec-white-space


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] Charset meta sniffing and supported encodings that are not rough ASCII supersets

[Darin Adler]

On Jun 1, 2007, at 1:57 PM, Henri Sivonen wrote:

The spec probably needs to be made more specific about the case  
where the ASCII byte-based algorithm finds a supported encoding  
name but the encoding is not a rough ASCII superset.


23:46 < othermaciej> one quirk in Safari is that if there's a meta  
tag claiming

 the source is utf-16, we treat it as utf-8
...
23:48 < othermaciej> hsivonen: there is content that needs it
...
23:52 < othermaciej> hsivonen: I think we may treat any claimed  
unicode charset

 in a  tag as utf-8


An example of a live site that needs this:

http://www.zingermans.com

-- Darin

Re: [whatwg] accessibility management for timed media elements, proposal

[Benjamin Hawkes-Lewis]

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:  | 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:  | 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  might have a music video featuring 
uncensored swearing, and another  might have the same video with 
the swearing beeped out.


--
Benjamin Hawkes-Lewis

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Kristof Zelechovski]

At least, MSXML does not preserve white space even where mixed content is
allowed.  I get ab when I XSLT a b.  I have to type   for all standalone spaces.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren
Sent: Saturday, June 09, 2007 11:26 AM
To: Michel Fortin; Ian Hickson
Cc: Henri Sivonen; whatwg List
Subject: Re: [whatwg] Still more comments and questions on Web Apps 1.0

On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:
> I'd agree they're mostly useless in a browser context, but when reading  
> HTML with the intent of reserializing it later, preserving the  
> whitespace around the document type declaration, the comments and the  
> root element can be beneficial for the readability of the final output.  
> I'd keep them there, just like XML does.

I don't think XML does that, actually.


-- 
Anne van Kesteren

Re: [whatwg] Still more comments and questions on Web Apps 1.0

[Anne van Kesteren]

On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin  
<[EMAIL PROTECTED]> wrote:
I'd agree they're mostly useless in a browser context, but when reading  
HTML with the intent of reserializing it later, preserving the  
whitespace around the document type declaration, the comments and the  
root element can be beneficial for the readability of the final output.  
I'd keep them there, just like XML does.


I don't think XML does that, actually.


--
Anne van Kesteren

Re: [whatwg] Steps for finding one or two numbers in a string

[Kristof Zelechovski]

That statement was not precise enough.  It applies to attribute names, not
to attributes as such.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Saturday, June 09, 2007 4:59 AM
To: Henri Sivonen
Cc: whatwg List
Subject: Re: [whatwg] Steps for finding one or two numbers in a string

On Fri, 14 Apr 2006, Henri Sivonen wrote:
> I think i18n political correctness has no place in attributes. I think 
> they should be ASCII only with the XML notion of whitespace.

I agree and believe the spec already requires this.