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

I've updated the ERT doc with the latest recommendations on BLINK. The URL
is:
http://www.w3.org/WAI/ER/IG/ert/#Technique7.2.A

Marquee is much the same and is at:
http://www.w3.org/WAI/ER/IG/ert/#Technique7.3.A

Please let me know if it misses some of your concerns.

I hope that the document is general enough so it does not limit the
implementation.

Chris

----- Original Message -----
From: Wendy A Chisholm <wendy@w3.org>
To: Evaluation & Repair Interest Group <w3c-wai-er-ig@w3.org>
Sent: Wednesday, October 20, 1999 2:22 PM
Subject: 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 15:52:10 UTC