WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Section 508 Standards Compliance and Scripts

for

From: Terence de Giere
Date: Sep 5, 2003 12:02PM

Fairly recent statistics indicate about 10 percent (plus or minus about
3 percent) of web site hits on public sites have JavaScript not
detected. There are lots of reasons why this might be. Users may have a
non script browser, or turn off scripting to avoid pop-up windows, or
for general security. The 10 percent figure here seems to indicate a
significant number of normal users have scripting off, which means
scripted content written to pages will be inaccessible to users not
using assistive technology.

Older browsers often fail with recently written JavaScript because they
do not support newer features of the language, although my guess is this
is less than 2 percent of users.

Note that it is the browser that supports and processes JavaScript, not
the screen reader. Generally scripts that write content or conditional
content to pages when the page loads is visible in screen readers.
Scripts that conditionally and dynamically write content to a page
dependent on a user action after the page loads is problematical for
screen readers, which cannot read the information created 'on-the-fly'.
Some assistive technology, such as IBM Home Page Reader, will extract
some information from dynamic script code, for example, link
information, and present it to the user as a static presentation. A text
browser like Lynx will not process any script.

Scripting does not run until the web page starts to load, and then loads
in sequence as the page is downloaded. It cannot run before the page
starts loading because it is on the page and the content of the page has
to be at least partially in the browser before the browser's script
interpreter can get at it. The statement regarding the distance
education application:

"[Software Package X] uses only minimal dynamic scripting for content presentation. It does use script to conditionally write some content to a page. Content rendered in this manner is written to the screen before the page loads, and can't be distinguished from standard content."

They are using the word 'loads' ambiguously to mean 'completely loaded'.
What is really happening is content is dynamically written to the page
*as* it loads. Screen readers can read this content however because it
is static once the page is fully loaded and does not depend on the user
interacting with scripting on the page other than just opening the page.

In a screen reader centric view of accessibility using a modern
graphical browser with scripting on, this should always work out, but
with other technologies and and the variable of user preferences, it can
certainly fail. It may be that nothing available for a particular kind
of application is fully accessibility compliant, so one chooses the
greater accessibility. A couple of years ago I queried a number of
vendors of online course materials at a government office expo, just a
few months before Section 508's deadline kicked in, and none of them
seemed aware of Section 508, although it was a feature of the exposition
being promoted by a number of agencies, and other vendors of software,
such as Adobe, with Acrobat, were addressing the issue. I feel that
courseware may be a little to a lot behind the curve when it comes to
accessibility, and their finding cost effective ways of incorporating it
into, or redoing their products.

The safe rule for accessibility is to assume scripts will not run, and
to write scripts in such a way that another process such as a server
side application, can provide the information if they fail. On the other
hand, client-side scripting can reduce the amount of hard coded content
on a site, and take a load off the server which would otherwise have to
do all conditional processing via interaction with the user using forms.

For example, a CD-ROM course consisting of HTML pages with conditional
scripting as described for the course in question could run in a
scripted browser with a screen reader on the computer's CD drive. If it
required server side processing, it would have to be installed on a web
server and run over a network, or a local web server would have to be
active or installed on the computer for it to work, and the files
installed so the local server could process them. So in some ways client
side scripting could reduce the complexities of licensing, installing,
and using the software, and reduce its cost, at the expense of some
assistive technologies that require a more static mode of presentation.

Interaction with an instructor is an essential part of efficient
learning, and courseware attempts to emulate this by being responsive to
the learner's input. Thus the efficiency of a course for the typical
user can be seriously affected by limitations in interactivity and the
speed of that interactivity. Client side processing of scripts
nonetheless remains a mine field of potential accessibility problems.
Courseware based on HTML is likely to be more likely accessible and
easier to use with assistive technology than courseware based on Flash
or PDF which, if accessible, can only be accessed by a couple of very
recent screen readers unless it can be converted to another format
first. Note that other accessibility factors besides scripting can cause
problems in courseware. Some vendors have used nested HTML frames, some
of them hidden, to provide a more fluid presentation, but these frames
'show' in most assistive technology, and create a navigational labyrinth
for non visual users that can negate other accessibility gains that
might be present.

Terence de Giere
<EMAIL REMOVED>





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