Re: [CSS2.1] Re: Possible additional CSS media type: 'reader'

>Yes, I agree, this isn't well stated. I propose that this text to be 
>amended to say that only one media type *in a single modality* shall 
>be supported.

Well, isn't that tautological? One media type per modality? Isn't a 
single modality a single modality, requiring a single media type?

But the issue here is devices that can simultanously output in 
multiple modalities. You could model that as requiring n discrete 
media types for n discrete modalities.

>But it would be completely unreasonable for Opera to turn off visual 
>styling the moment it starts to speak. We would want to be able to 
>specify "@speech {img[alt] {content: attr(alt)}}" and thus read the 
>alt text, but show the image.

True. A good example, actually. I wish people could come up with more of those!

>There are differences between a multimodal browser and a speech 
>browsers. One approach could be to have two aural media, one for the 
>UAs with no visual components and one for audiovisual UAs.

Possibly a good idea, but pretty complicated. Couldn't that variation 
be encompassed by different attributes, properties, or selectors?

>The multimodal applications I have seen so far are (and should be) 
>highly redundant, they work with either mode alone (sound *or* 
>vision). Making applications that require both (sound *and* vision) 
>would not only be in breach of WAI guidelines (for hearing 
>disabilities),

That is a serious misunderstanding. Just in general, when you add 
captions you don't turn off audio, and when you add audio 
descriptions you don't turn off video. WAI guidelines are generally 
concerned with *adding* features, not *reducing* them.

Cf. <http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-synchronize-equivalents>

>>For any time-based multimedia presentation (e.g., a movie or
>>animation), synchronize equivalent alternatives (e.g., captions or 
>>auditory descriptions of the visual track) with the presentation.

Add, don't subtract.

We are not making screen readers accessible to the deaf! We are not 
saying that the voice output of screen readers has to be captioned!

>  they would be very liable to break. I am not convinced there are 
>use cases for that kind of applications, it is not where our 
>interest lie and I am not aware of anyone else interested in that.

Applications that require or at least use sound, vision, and touch 
simultaneously are in use in the real world and were one genesis of 
my proposal. The *requirement* that such multimodal outputs be 
*required* and not simply *used* also sets the bar too high.

>  Thus I don't think a 'reader' media type is ready for CSS 2.1,

There may not be a lot of time to write it up properly, but it can't 
wait for CSS3. It should have been in CSS1, since the behaviour in 
question was in use even then.


-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Expect criticism if you top-post

Received on Friday, 14 November 2003 08:59:17 UTC