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

Hi All,

Looking aroud the web there is a fairly high use of scripting (in particular
Javascript) to add dynamic effects and user experience to websites. Is this
necessary, helpful, wise, or a complete mistake?

There are (in my humble opinion, which is all this email is) lots of
legitimate uses of scripts. For example, automatically validating form data
on the client side, rather than having to transmit it, process it, and then
return it with the error message, is helpful for those in whose browseers it
works, and so long as the function is also provided for those without
script-capable browsers, doesn't cause any real problems.

Similarly, improving the presentation of pages can be a fine thing, and can
be very important for some groups of users (as well as purse-string
holders). So long as the appearance or usability of the page is improved,
and the WCAG checkpoint quoted by Kelly is followed there should be no
problems. In addition, there are a number of ways in wihch scripting can be
used to improve accessibility features of a page.

There are however things that scripts should not do. In particular, they
should not take the [pace of ordinary features of the Web - content, or
links, are easily produced in languages like HTML. One of the principles
behind te design of the web itself was to use the simplest and least powerful
mechanism that would get the job done. This meant that it was as easy as
possible to make it work across the huge and growing variety of platforms
people use (from telephones to supercomputers, from a 20-character braille
line to wide-screen quadrophonic audio/video).

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]

Received on Sunday, 16 January 2000 10:31:13 UTC