W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2000

Re: Scripts on the web Re: Does CSUN Care About Web Accessibility

From: Wendy A Chisholm <wendy@w3.org>
Date: Thu, 17 Feb 2000 15:24:00 -0500
Message-Id: <4.2.0.58.20000217150707.00a19f00@localhost>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:01 GMT