WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: 508 Checkpoint L

for

From: Terence de Giere
Date: Nov 14, 2001 4:29PM

Re: 508 Checkpoint L
This checkpoint is worded so clumsily.
Scripting will not run if it is not supported by the browser or if it is
turned off. Any information provided by the script is not accessible
under these conditions.
Scripting sometimes works with screen readers if it is supported by the
browser used with the screen reader, but screen readers cannot process
information that is interactively created and written to the screen
on-the-fly by scripting, such as a scripted drop-down menu. Under these
conditions some scripts run and work fine, and some scripts run and the
content is not processed with special access technology. Accessibility
guidelines for user agents (browsers) require that browsers allow the
users to turn off scripting, since in many cases the page content cannot
be rendered properly with special access technology.
Under some circumstances, the script code will be written to the screen
and be seen or be read by a screen reader. Older browsers that do not
support the HTML SCRIPT element will display the code unless is is
commented out <!-- --> using an SGML comment within the SCRIPT element.
This may be the reason for the reference to a jumble of letters and
numbers. The HTML specifications require browsers to try to render, if
possible, the content (but not the attributes) of any element it does
not support. The SCRIPT element normally contains JavaScript which is
text, and so a browser is supposed to display this text if it does not
recognize the SCRIPT element. Commenting it out prevents display in
older browsers. Browsers that support scripting follow the convention
that commented-out script in the SCRIPT element should in fact be
processed and not ignored, and should not be displayed even if it is not
commented out..
The HTML NOSCRIPT element is used to convey alternative content if
SCRIPTING is unavailable by being not supported or turned off. Older
browsers will display this content even if they do not support scripting
because of the rule for the browser to display the content of
unrecognized HTML elements. In a new browser turning off scripting
activates the NOSCRIPT content. NOSCRIPT can contain many of the typical
HTML elements such as paragraphs etc. This is one way to handle the
"functional text" requirement in 508 rule paragraph L.
Another way would be to provide a link to a separate HTML page to
provide direct access to a text version of the information provided by
the script. If the information in the script is put as text directly on
the same page as the script, what is the purpose of providing the script
in the first place?
A potential problem is with scripts that run but are not fully
compatible with the browser being used. In this case normal users also
have accessibility problems because of error messages or because the
script hangs up. If alternate content is provided in the NOSCRIPT
element, it will be unavailable under this scenario because scripting is
on. In this case alternate content needs to be provided directly on the
page (which sort of defeats the reason for the script in the first
place), or on an alternate page.
Also, even if alternate content renders and works properly with screen
readers and audio browsers, there is a usability problem if the
scripting is used with certain HTML elements. For example, using an HTML
FORM with a drop-down list of links activated by JavaScript without a
backup server-side program or script to process the links is effectively
a dead control when scripting is unavailable. So even if the alternative
content works fine, that dead control is still on the page and can
confuse users.
The two preceding paragraphs cover the situation that represent the gray
area for this rule, with alternate content not being rendered for the
user, or being rendered along with inaccessible content that initially
will appear to the user as functional until the user tries to use it.
Putting the NOSCRIPT alternative before the inaccessible control may be
better than putting it after the control.
Mouseover scripts are often trivial, meaning the page still works OK
with assistive technology and no real information in the page content is
lost if the script does not run. Some browsers, such as the now
out-of-production pwWebSpeak32 audio browser, would render "Unsupported
script" at every location a script appeared on a page. Using NOSCRIPT to
provide some explanation to the user of what the script on the page does
puts the user at ease that something significant is not missing.
For example:
<NOSCRIPT><P>Scripting on this page visually highlights images within
links when the mouse passes over the image. If you do not or cannot use
a mouse or your browser does not support scripting, these links will
still function properly.</P></NOSCRIPT>
The 508 rules appear to be aimed primarily at screen readers, which
typically are used these days with a graphical browser, usually Internet
Explorer. The W3C accessibility guidelines address a wider range of
technology, including text and audio browsers, cell phones, older legacy
special access technology and older browsers.
Browsing the Web with screen readers, text, and audio browsers, and
older browsers can be very trying because the Web is pretty
nonfunctional using these technologies with heavily scripted pages. Some
groups may have a security requirement to keep scripting off.
I have a friend who uses a screen reader and an audio browser. The
system is a PC with Windows 3.1, and Netscape version 3 (with the screen
reader) and an old version of the pwWebSpeak audio browser. Impaired
users are less likely to be using the most recent version of operating
system, screen reader, or browser. They are often under greater
financial and mobility restraints and updating equipment is more
difficult for them.
The 508 rules provide a minimum baseline accessibility for users that
need special technology. Better is meeting the W3C Priority 2 Guidelines.
Terence de Giere
<EMAIL REMOVED>
>=============================>
>Date: 14 Nov 2001 11:12:51 -0600
>From: "Leo Smith" < <EMAIL REMOVED> >
>Subject: 508 Checkpoint L
>
>Hi All,
>
>
>I am presently working on a collaborative effort to produce a set of
>508 tutorials/guidelines for folks in the University System where I
>work.
>
>
>My charge is explaining and providing examples for checkpoint L,
>the JavaScript checkpoint, which I personally consider to be the
>checkpoint where most pitfalls might occur.
>
>
>I have almost finished writing my contribution, but am a little
>confused over some of the access-boards wording with regard to
>this checkpoint.
>
>
>Specifically:
>When authors do not put
>functional text with a
>script, a screen reader will often read the content of
>the script itself in a meaningless jumble of numbers
>and letters. Although this jumble is text, it cannot be
>interpreted or used. For this reason, the provision
>requires that functional text, that is text that when
>read conveys an accurate message as to what is being
>displayed by the script, be provided."
>
>Does this mean that ANY Javascript
>code has to have functional
>text explaining its purpose, even if the purpose of that code is
>merely "behind the scenes" stuff that does not affect the actual
>information delivered to the user - for instance, browser detection
>scripts? Is the code between the <<script> tags read by a screen
>reader, or are they just referring to script code that appears with
>event handlers?
>
>
>My common sense tells me that what they are saying is that when
>a script is used to present information on the screen to the user,
>such as rollovers that provide more information about the
>destination of a link, that such information is also provided in a text
>format that can be read by assistive technologies.
>
>
>I would appreciate any and all input.
>
>
>Thanks!
>
>
>Leo.
>
>Leo Smith
>Web Designer/Developer
>USM Office of Publications and Marketing
>University of Southern Maine
>207-780-4774
>


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