- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 30 Aug 1999 09:58:08 -0400 (EDT)
- To: thatch@us.ibm.com
- cc: w3c-wai-ua@w3.org
My comments marked CMN, Jim's marked JT Some checkpoints have been snipped. On Thu, 26 Aug 1999 thatch@us.ibm.com wrote: 5.5 Allow the user to turn on and off rendering of captions. n/a HPR does not render closed captions. Clarification: Use "closed captions" since "CAPTION" is an element. CMN I agree - this has been confusing in the reviews I have done with Amaya (which, as an editor, requires the caption element for all tables) and Opera. JT User Interface (Priority 1) 5.6 Allow the user to turn on and off animated or blinking text. n/a HPR Does no render animated text. 5.7 Allow the user to turn on and off animations and blinking images. n/a similar 5.9 Allow the user to turn on and off support for user style sheets. n/a similar CMN Actually audio styling is as relevant as visual styling. Support for style control and suport for CSS are not necessarily the same thing, and that should be clarified. But I think this and the next checkpoint are certainly applicable. JT 5.10 Allow the user to turn on and off support for author style sheets. n/a similar 5.11 Allow the user to turn on and off support for spawned windows. n/a similar 6.1 Allow the user to control font family. no This is for the text view. Since HPR's designated audience is blind users, 6.1-6.6 should not apply. CMN This cuts to a philosophical argument which is fairly central to this process. If it is OK for a User Agent to be applicable only to a certain market segment (blind users, people with 21" monitors, whatever) should they be able to conform to the User Agent Guidelines? It seems that the division we currently have for conformance breaks down here - Jim argues cogently that HPR is not universally accessible and was never intended to be. On the other hand it is an assistive technology for people with functional restrictions which mean that substituting audio output for visual output provides accessibility. Yet as I understand it HPR (bundled with Netscape) is an independent browsing solution, and HPR on its own is half a piece of software that does nothing at all. JT 6.2 Allow the user to control font size no ditto 6.3 Allow the user to control foreground color. no ditto 6.4 Allow the user to control background color. no ditto 6.5 Allow the user to control selection highlighting (e.g., foreground and background color). no ditto 6.6 Allow the user to control focus highlighting (e.g., foreground and background color). no I assume this is what we see in Windows standard list boxes. 6.14 Allow the user to control speech playback rate. yes I am taking speech playback to mean synthesized speech! But my interpretation has to be wrong because these are not guidelines for us. CMN I think your interpretation of the checkpoint is correct. I am not sure why these guidelines are not for HPR JT 2.3 Provide information to the user about the current keyboard configuration. yes Clairification sought. If keyboard is not configurable, is this met? Is this just an expansion of provide documentation? CMN That is how I have interpreted it. JT Device Independence (Priority 1) 1.1 Ensure that all functionalities offered through the user interface may be operated through standard input device APIs supported by the operating system. no There are features not available with the mouse. This should *not* be non-compliance on an accessibility checklist. In fact they are not available without speech output. (The settings menu.) But that was intended for the target audience. CMN This raises the same question about being able to design for a single intended audience that I discussed above. JT 1.2 Ensure that the user can interact with all active elements of a document in a device independent manner. no JavaScript elements. CMN I have a fervent hope that the Javascript Event model of HTML 4.0 is changed to a less device-dependent one, as the HTML 4.00 specification itself promises. JT 1.6 Ensure that all messages to the user (e.g., warnings, errors, etc.) are available through standard output device APIs supported by the operating system. yes Note, some error messages come as standard dialogs from Netscape, but HPR messages meet 1.6. CMN Since HPR requires Netscape, I would suggest that HPR should be assesssed on the basis of the mesages from Netscape as well as those it generates itself. JT 12.1 Use and provide accessible interfaces to other technologies. n/a We are an assistive technology; we don't want to provide API's. We shouldn't. CMN Which restricts the functionality to people who meet all the functional requirements of the particular assistive technology, rather than being able to use assistive technology on top of this. 9.3 For dependent user agents. Allow the user to view a document outline constructed from its structural elements (e.g., from header and list elements). yes The wording is not good. Don't we already have a 'navigate' by structural elements. Is this a technique for 8.6? CMN I agree. JT 2.5 Allow the user to turn on and off author-specified keyboard configurations. no Could this possibly be saying, after arguing for AccessKey, now allow it to be turned off! AccessKey is a bad idea. CMN I am not sure if it is a bad idea, but I certainly think that it should have been thought through a lot more carefully. JT For Links (Priority 2) 9.5 Make available whether following a link will involve a fee. no Can this be determined? CMN Good Question. There doesn't seem to be any method at the moment. JT For Frames (Priority 2) 5.12 Allow the user to turn on and off rendering of frames. yes Yes because of frame expand, but I think this is an unrealistic checkpoint. What does it mean to have rendering of frames truned off. Is this a request that provide access to NOFRAMES content. If not, probably should be. For Standards and Conventions (Priority 2) 11.2 Support appropriate W3C Recommendations. yes But only the appropriate ones! Does this mean if we do not support ABBR and ACRONYM (P1) we are not P2 compliant or not P1 compliant? 4.2 Allow the user to configure the visual arrangement of user interface controls. no This is an unreasonable accessibility checkpoint. CMN For universal accessibility as a P3 I think it is not unreasonable. For an interface that only has audio and keyboard components it is not applicable. JT 5.14 Allow the user to turn on and off automatic page refresh. no Is this something in control of browser? CMN Sure. Lynx doesn't ever turn them on, although they are passed to the reader to activate the refresh whenever they want (as a static link). Charles McCN
Received on Monday, 30 August 1999 09:58:10 UTC