- From: Chris Ridpath <chris.ridpath@utoronto.ca>
- Date: Thu, 21 Oct 1999 09:53:09 -0400
- 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