- From: Wendy A Chisholm <wendy@w3.org>
- Date: Thu, 17 Feb 2000 15:24:00 -0500
- To: Charles McCathieNevile <charles@w3.org>, Kelly Ford <kford@teleport.com>, WAI GL <w3c-wai-gl@w3.org>
going through older mail... Charles, part of your list of what scripts should _not_ be used for is already included in the HTML module of the techniques document. refer to http://www.w3.org/WAI/GL/WCAG10-HTML-TECHS/#scripts-gt What is not included I will add. I would disagree that all browser sniffing by scripts is a bad thing. An example that I heard yesterday is that Netscape 4.0 and 4.01 have very bad support of style sheets. Therefore, an author can determine that those browsers should receive the base style sheet while other browsers, such as Netscape 4.5, receive a more complicated style sheet. What I do agree should be avoided is sniffing for only the most recent browser and telling everyone else, "you need to upgrade." especially when they only sniff for Microsoft and Netscape leaving Opera and other recent browers out of the fun. The other techniques you asked about: 1. Dancing or scrolling status lines 2. "rollover" scripts - providing a highlight for a mouse rollover. From what I remember, older screen readers used to have a problem with scrolling status lines. Text in marquees, whether created with a MARQUEE element, a script or a Java applet, was read as text appeared on the screen whether in the status line or in the main window it was read. We need to recreate these tests with today's browser and screen reader configurations. For people who read slowly, if there is important information that scrolls they may not be able to read it in time. Also, as I understand it, for some people with attention disorders they may be so drawn to the movement that the rest of the page almost becomes invisible. Rollover scripts can be a problem if they pop up additional information. I have not heard of problems if they just change the appearance of a link, unless new information is being provided that is not obvious. I think the general statement of scripts is "use them with care." Last year I worked on scripts and style sheets for a while and wrote up some thoughts which are available at: http://sun.trace.wisc.edu/~chisholm/dhtml/ This is not completely up to date with where i left off, nor is the work completed. I will be returning to this work in the near future. --wendy Charles wrote: >SO what should scripts not be used for? Here is my preliminary list. If >people are interested in following this up, please reply to the >w3c-wai-gl@w3.org list so the discussion can be incorporated into the work >being done by the WCAG group. > >0. Generating the content of a page only by means of scripts. >1. Making a link (href="javascript:anything"). >2. Form submission. >3. Browser sniffing to require a particular version > Note: There are legitimate uses of browser sniffing to improve > presentation of functionality, but only where the functionality doesn't > rely on having a particular browser. >4. Using a script to force a new window to open. > >And the things I don't know about but would be interested in user feedback >on... > >1. Dancing or scrolling status lines >2. "rollover" scripts - providing a highlight for a mouse rollover. (I have > some separate thoughts about this too...) Does this cause a problem for > anyone? > >Hmm. I'm sure there's more, but it doesn't spring to mind. > >cheers > >Charles McCN >-- >Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 >W3C Web Accessibility Initiative http://www.w3.org/WAI >21 Mitchell Street, Footscray, VIC 3011, Australia > > > >On Sat, 15 Jan 2000, Kelly Ford wrote: > > Hi All, > > Many in the disability know the name CSUN as a leader in promoting > disability accessibility. Their conference held each March is a leading > gathering place to share information on the latest developments with > access > technology. That's why I find it disheartening to say the least to see > one > of the latest offerings from the staff at CSUN, namely the web site where > one can browse the proceedings of this year's conference well in advance > having a large problem with web accessibility. This resource can be > found at: > > http://www.csun.edu/cod/conf2000/proceedings.html > > The problem is that this web site violates a critical priority 1 guideline > in the Web Content Accessibility Guidelines and as a result locks out > people who use certain web browsing combinations. All of the conference > papers found on the proceedings page are linked with Javascript commands > meaning that certain people who use the Lynx web browser can't access this > resource. I also believe that users of Webspeak and Home Page Reader will > have difficulty on this page but would appreciate confirmation or > correction of this point. I believe I have the latest version of both > browsers and could not access the papers on the page with either of these > browsers. > > The Web Content Accessibility Guidelines clearly state: > > 6.3 Ensure that pages are usable when scripts, applets, or other > programmatic objects are turned off or not supported. If this is not > possible, provide equivalent information on an > alternative accessible page. [Priority 1] > > For example, ensure that links that trigger scripts work when scripts are > turned off or not supported (e.g., do not use "javascript:" as the link > target). If it is not possible to > make the page usable without scripts, provide a text equivalent >[etc] -- wendy a chisholm world wide web consortium web accessibility initiative madison, wi usa tel: +1 608 663 6346 /--
Received on Thursday, 17 February 2000 15:20:11 UTC