WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: 508 Checkpoint L

for

From: Terence de Giere
Date: Nov 18, 2001 10:54PM

The best way to check if a Web page with a script is accessible is to
test the page in a browser that does not support scripting, or with a
browser that allows scripting to be turned off (and test the page with
the scripting turned off).
Certain scripts can be written in a way that allow normal function of a
page if scripting is not processed. For example pop-up windows can be
written so that if scripting is off or not available, the material will
open in a new full sized window or the browser will go to the new page
in the same window (for those browsers that create new windows - text
and audio browsers do not create new windows, and new windows can also
confuse non-visual users using screen readers). However many kinds of
scripts require alternative content to provide users with an equivalent
non-script function.
Previous and Next pages, if written as pure scripted links, will be dead
links in some special access technology. If the links are "hard wired"
as regular links and scripting is also present and is on, say, using the
onclick attribute in the link to provide a link to a URL, then the
script will activate in a scripted browser on the mouse click, and in a
non-scripted browser the regular link will still work, although it is
redundant to use such a script. If the JavaScript accesses the browser
history to get back to a page, then such a link will fail if scripting
is off. A normal link is the most robust way to get somewhere when using
special access technology.
Device independence in scripting means that one is not limited to just a
mouse, but the script will work with a keyboard or other device. But
scripting is always dependent on the browser being able to run the
script. A non-script device will not run the script no matter whether it
is written device independently or not. Scripting can greatly improve
usability of pages for normal users, but for now it is also a minefield
when accessibility is considered.
Server-side scripts however are accessible because the user must submit
a form to the server, which is then processed by the server--which is
under the developer's control, not the user--and which then returns a
new page to the user. Form based client-side scripts that also have a
server-side backup can run if scripting is available in the browser, and
processed on the server if browser-side script processing is not
available. Highly interactive client-side scripts that create
instantaneous changes on the page generally are inaccessible because a
form-based submission to a server cannot duplicate the effect, so some
kind of alternative content is required.
The best test for accessibility with scripted pages is to test the page
with a browser that does not support scripting. If the page does not
work under these conditions, it is inaccessible. Using a text browser
such as Lynx or the W3C's Amaya browser is a good way to check pages for
accessibility because these browsers do not support scripting. Amaya
also has alternate views of pages, such as a text only view, a headings
only outline view, and a links-only view. Netscape and Internet Explorer
also allow scripting to be turned off, but it is inconvenient.
The Opera browser is an ideal graphical browser for testing pages
because it provides a non-Microsoft, non-Netscape view of a page as well
as a non-Microsoft, non-Netscape implementation of script processing,
and allows fairly easy access to quickly turn off scripting. It can also
turn off frames, tables and auto-redirects. It can quickly turn off
images. It can also be set to prevent pop-up windows, while leaving
other scripting on. It can thus reasonably mimic a wide range of special
access technology.
These user controls in Opera are part of the W3C Web Accessibility
Initiative for user agents (browsers). User agent accessibility
guidelines give such great control to the user that a user could
potentially undo just about everything a developer could put in a page
as far as format and function. The idea is to give full control of the
page back to the user. Not everyone will use this of course, only those
that have a definite debility that requires accessing the information in
the page a different way to make sense of it. This requires making the
information in a page accessible in many different modes, not just via a
computer screen with a mouse.
Terence de Giere
<EMAIL REMOVED>

>
>Date: 15 Nov 2001 12:55:00 -0600
>From: "Kitzzy Aviles" < <EMAIL REMOVED> >
>Subject: Re: 508 Checkpoint L
>
>Along the lines of this question ...
>
>Lets say I create some Javascript to automatically link to next and previous
>pages of a sequence of pages. As long as the events are not device dependent,
>would this be accessible? Or must all Javascript content be accessible when it
>is turned off? I have heard so many different things. What does the actually
>Section 508 law require? Is it just that the use of Javascript be accessible
>Javascript or is it that all content be accessible when Javascript is turned
>off?
>
>Thanks,
>Kitzzy
>
>Kitzzy Aviles
>Specialist, Techranger Development & Training
>Course Development & Web Services
> <EMAIL REMOVED>
>

---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/