- From: Leonard R. Kasday <kasday@acm.org>
- Date: Wed, 20 Oct 1999 11:49:45 -0400
- To: "Gregory J. Rosmaita" <unagi69@concentric.net>, Evaluation & Repair Interest Group <w3c-wai-er-ig@w3.org>
Regarding Al's point on the dangers of BLINK >I have a problem with soft-pedaling the PWD issue in this case. ... > The point about BLINK is that it is a hazard which may induce >[phototropic?] seizures in some people. I agree that this is a more serious case. However, if we're going to push this point, I think we need to be quantitative. For example, is there evidence that blinking a single letter is dangerous? As I write this, my text cursor is blinking, and I haven't heard that described as a safety hazard. Is there data on this? As for the guideline, I overall agree with it. However, 1. I think the user should also have the ability to replace blink with any other style, e.g. font, color, etc. This has the problem that the implied semantics (viz. "hey this is really really important!!!") are lost. But this is a general problem with CSS anyway and I assume that we're going to do something about it. 2. I don't think we should be so specific about the user interface. I would want a general statement like "The tool shall by default replace BLINK with STRONG, but give the author the option to override this choice with EM, or any CSS defined style. The tool shall offer the user an explanation of why CSS BLINK is undesirable." The difference between this wording and the wording in the minutes (reproduced below) is that the wording in the minutes prescribes a specific "wizzard" style interface, with prescribed steps in a prescribed order. Read strictly, it would e.g. prevent a tool developer from offering a dialog box which presents all options simultaneously, with the warning explanation next to the choice of CSS blink. We should specify function, not user interface here. If people feel strongly that we've got to be specific, we should at least have a general disclaimer that any other user interface with equivalent functionality is permitted; and this disclaimer should be strongly emphasized (e.g. by using BLINK <smile> ). Len Here's the wording in the minutes I'm referring to: >Resolved: Repair strategy will consist of the following steps: >1) remove BLINK or replace with STRONG or EM >2) if author chooses "No" when prompted to replace BLINK, issue a dialog >containing an explanation of accessibility and usability problems posed by >BLINK >3) if author chooses "Use BLINK Anyway", prompt the user (or automatically) use >CSS to achieve blinking effect so that end user has control over presentation ------- Leonard R. Kasday, Ph.D. Institute on Disabilities/UAP, and Department of Electrical Engineering Temple University Ritter Hall Annex, Room 423, Philadelphia, PA 19122 kasday@acm.org (215) 204-2247 (voice) (800) 750-7428 (TTY)
Received on Wednesday, 20 October 1999 11:46:27 UTC