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

I agree with Len's concerns, particularly that we want a general 
statement.  I think his proposal works well.

--w


>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 14:24:49 UTC