MARQUEE

Also, re. MARQUEE...

That's typically used for a series of objects.  I'd suggest providing a
convenient way to break it into a bullet list.

I'd also suggest omitting the H1 H2 ...  I've never seen MARQUEE used for
that.

And adding a note, suggesting CSS styling, after SPAN.

Len

At 03:52 PM 10/20/99 -0400, you 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)
>
>
>
-------
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:40:56 UTC