- From: Chris Hofstader <ChrisH@Freedomscientific.com>
- Date: Thu, 30 Oct 2003 18:26:00 -0500 (EST)
- To: "'Joe Clark'" <joeclark@joeclark.org>, www-style@w3.org
- Cc: Screen-Reader-Makers <"Screen-Reader-Makers:;"@dr-nick.w3.org>
Hi, I can say, on behalf of the Freedom Scientific team, the authors and publishers of JAWS, the screen reader used by the vast majority of blind people who use the Internet, that I entirely support Mr. Joe Clark's statement on this matter. It would be useful to all who would intend upon making the WWW accessible to people with vision problems to have a media type for screen readers. Sincerely, cdh Chris Hofstader VP, Software Engineering Freedom Scientific, Inc. 11800 31st Court N. St. Petersburg, FL 33716 PH: (727)803-8000 ext. 1061; (800)444-4443 Fax:(727) 803-8001 email: ChrisH@freedomscientific.com Check out our website! www.freedomscientific.com -----Original Message----- From: Joe Clark [mailto:joeclark@joeclark.org] Sent: Thursday, October 30, 2003 9:15 AM To: www-style@w3.org Cc: Screen-Reader-Makers Subject: 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). <http://www.alistapart.com/articles/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. MULTIMODAL DEVICES 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 simultaneously: 1. speak 2. manipulate the screen (as by scrolling or highlighting words or phrases as they are spoken) 3. produce Braille <http://www.alistapart.com/articles/fir/#css-fixed> 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. CURRENT MEDIA TYPES These adaptive technologies appear to combine the braille, screen, and speech media types. The spec tells us: <http://www.w3.org/TR/CSS21/media.html#media-groups> >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 >types. 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. MAKING SCREEN READERS LEGAL 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: <http://www.w3.org/TR/CSS21/media.html#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.) APPLICABILITY TO ACCESSIBLE MEDIA 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. <http://joeclark.org/access/dvd/guidelines/?CSS>). REFORMULATIONS 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.' MINIMUM RECOMMENDATION 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. FUTURE DEVICES IN GENERAL 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 Monday, 3 November 2003 10:04:07 UTC