W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > October 1999

Re: BLINK repair mechanisms (calling all CSS gurus!)

From: Leonard R. Kasday <kasday@acm.org>
Date: Wed, 20 Oct 1999 11:49:45 -0400
Message-Id: <>
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> ).


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
>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
(215) 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Wednesday, 20 October 1999 11:46:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:29 UTC