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

let me restate my position, i mixed a couple things.

1.  i don't think we want to use headers to replace blink (or  marquee)
2.  with the span element, suggest using CSS properties.

we could then add a 3rd bullet point that includes len's comment, "The
tool shall offer the user an explanation of why CSS BLINK is 
undesirable."  The "undesireableness" refers back to the HTML4 spec where 
it says that css blink may or may not be supported, as gregory pointed 
out.  perhaps we ought to be a bit more specific in regards to that.

--w

At 03:52 PM 10/20/99 , Chris Ridpath wrote:
>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 16:32:04 UTC