Possible additional CSS media type: 'reader'

An article of mine was recently published at A List Apart on the 
accessibility of Fahrner Image Replacmenent (FIR).


The main question was: How do screen readers work with text that is 
marked up using FIR? The answer was: Not very well. And, since the 
technique canonically uses either display: none or visibility: 
hidden, screen readers in fact should probably never with the 
technique. Most or probably all of the time, they should not read 
text that is encoded in FIR.

The article pointed out a fact that might not be well-known in the 
CSS Working Group-- screen readers are multimodal devices. Jaws, 
Window-Eyes, and IBM Home Page Reader can all do the following 

1. speak
2. manipulate the screen (as by scrolling or highlighting words or 
phrases as they are spoken)
3. produce Braille


Hence, screen readers are multimodal devices. I personally know two 
people who use Braille and voice at the same time, and I've used IBM 
Home Page Reader in voice-and-highlighting mode.

These adaptive technologies appear to combine the braille, screen, 
and speech media types. The spec tells us:


>Media types are mutually exclusive in the sense that a user agent 
>can only support one media type when rendering a document. However, 
>user agents may have different modes which support different media 

I take this to mean:

* A device can use one output method at a time to render a document.
* The device may change from mode to mode-- as long as only one mode 
is in use at any time.

The current CSS media types do not describe real-world screen-reader 
usage, since those technologies use one or more combinations of 
output methods at once, and we don't have a media type for that yet.

As such, either the spec does not apply to screen readers or screen 
readers are in violation of it.

I suggest that these adaptive technologies be brought explicitly into 
the fold of CSS through the creation of a new media type, 'reader,' 
which would allow for simultaneous multimodal output.

The media type 'reader' can be described as belonging to the 
following CSS2.1 media groups:


  Type     |cont./paged | visual/audio/speech/tactile | g./b.| inter./stat
  'reader' | continuous;| visual,audio,speech,tactile | both | interactive

I don't pretend to know how this would work or what the definition 
should say. However, screen-reader makers CSS support is inconsistent 
at the moment in part because it is not clear at all how a multimodal 
device should deal with unimodal media types and the specific 
browsing environments actual blind people use. Examples:

* Some screen readers may be tied to a certain visual browser, while 
others may be able to parse HTML themselves, or both, but screen 
readers are in those cases still using visual styles to govern output 
in voice.

* There is increasing support for aural CSS (one leading manufacturer 
is known to be working on it).

* There is no support for the braille media type that I know of.

* No product I know of uses DOCTYPE-switching or other kinds of 
custom CSS rendering.

(The Emacspeak program may be the exception to the rule in all those 
cases, but very few people indeed use Emacspeak.)

The media type of 'reader' would be a departure from current CSS 
specifications because it would encompass simultaneous multimodal 
output. Note that this is really the norm in accessible media:

* Captioning and subtitling involve video, audio, and written words.

* Audio description involves video and two interleaved streams of 
audio. Some forms of dubbing do the same, while other kinds of 
dubbing replace the original audio.

* Interactive menu systems can have visual menu layouts and speech 
interfaces (as for DVDs and set-top boxes; Cf. 

The current typically-unimodal CSS media types do not accurately 
describe adaptive technology and other accessibility features.

Instead of excluding these devices from the standard or setting up 
the standard so that the devices violate it, I am suggesting a 
reformulation of the standard to make such devices explicitly legal.

There is another wrinkle. Since we're already talking about screen 
readers, we should also discuss screen-magnification software, which 
some visually-impaired people use alone or with screen readers. When 
used alone, they are clearly of media type 'screen,' but their 
behaviour-- inverting colours or rendering as black-and-white; 
magnifying to different degrees; magnifying text but not graphics or 
both at once-- is not readily captured in CSS. (Even some 
quasi-mainstream technologies are de facto screen magnifiers-- Opera 
and Acrobat Pro 6 come to mind. Windows and Mac OS X can magnify the 
screen themselves.) The Working Group may wish to update whatever 
media type is required to reflect this real-world magnifier usage, or 
even add another media type, such as 'magnifier.'

Even though I have good knowledge of accessibility, I reiterate that 
I'm not an expert in CSS media types. (I have talked this issue over 
with some experts, though.) I don't have a detailed suggestion as to 
what this new spec should say, but I want to get everyone talking 
about the issue, and at a minimum promptly propose the new 'reader' 
media type for inclusion in CSS2.1 by the W3C CSS working group.

Note that this may be opening up a large *but necessary* bucket of 
worms: Over time, new devices will be invented that do not conform to 
the existing media types. (Or, as in this case, the true nature of 
existing devices is pointed out after the spec is originally 
written.) Perhaps the CSS Working Group might wish to make it 
possible for future devices to define their own media types or select 
from existing media-type components. This is going to come up again, 
and the current system of defining CSS media types may be too 
reactive to ensure that new and old devices actually comply with the 
specs. Though related, all this is of course a separate task from the 
current issue of screen readers and magnifiers.

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

Received on Thursday, 30 October 2003 12:06:10 UTC