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

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

From: Chris Ridpath <chris.ridpath@utoronto.ca>
Date: Thu, 21 Oct 1999 09:53:09 -0400
Message-ID: <006701bf1bcb$9c6578b0$b040968e@ic.utoronto.ca>
To: "Evaluation & Repair Interest Group" <w3c-wai-er-ig@w3.org>, "Wendy A Chisholm" <wendy@w3.org>
> 1.  i don't think we want to use headers to replace blink (or  marquee)
>
OK. I'll remove the headers suggestion.

> 2.  with the span element, suggest using CSS properties.
>
I'm not quite clear on this one... If the user selects SPAN as a replacement
for BLINK then allow them to set the SPAN attributes (such as font family,
font size etc.)?

>the  tool shall offer the user an explanation of why CSS BLINK
> is undesirable."
>
We don't have anything in the ERT that suggests rationale for the techniques
to the user. Bobby offers rationale in their report and A-Prompt puts it in
the user help file. But should we add something to the ERT that specifies
the rationale?

Chris

----- Original Message -----
From: Wendy A Chisholm <wendy@w3.org>
To: Chris Ridpath <chris.ridpath@utoronto.ca>; Evaluation & Repair Interest
Group <w3c-wai-er-ig@w3.org>
Sent: Wednesday, October 20, 1999 4:32 PM
Subject: 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 Thursday, 21 October 1999 09:53:27 UTC

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