E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Leo Smith
Date: Wed, Nov 14 2001 9:12AM
Subject: 508 Checkpoint L
No previous message | Next message →

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/

From: Jim Thatcher
Date: Thu, Nov 15 2001 12:06AM
Subject: Re: 508 Checkpoint L
← Previous message | Next message →

Leo,
I tried to tackle that question in the 508 tutorial section on JavaScript, http://jimthatcher.com/webcoursea.htm. I believe the basic issue is whether or not the information provided through JavaScript is available to a screen reader.
Jim
= EMAIL ADDRESS REMOVED =
Accessibility Consulting
http://jimthatcher.com
512-306-0931

From: Terence de Giere
Date: Wed, Nov 14 2001 4:29PM
Subject: Re: 508 Checkpoint L
← Previous message | Next message →

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 ADDRESS REMOVED =
>=============================>
>Date: 14 Nov 2001 11:12:51 -0600
>From: "Leo Smith" < = EMAIL ADDRESS 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/

From: Kitzzy Aviles
Date: Thu, Nov 15 2001 10:54AM
Subject: Re: 508 Checkpoint L
← Previous message | Next message →

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 ADDRESS REMOVED =
>>> = EMAIL ADDRESS REMOVED = 11/14/01 07:25PM >>>
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 ADDRESS REMOVED =
>=============================>
>Date: 14 Nov 2001 11:12:51 -0600
>From: "Leo Smith" < = EMAIL ADDRESS 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/

From: Terence de Giere
Date: Sun, Nov 18 2001 10:54PM
Subject: Re: 508 Checkpoint L
← Previous message | No next message

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 ADDRESS REMOVED =

>
>Date: 15 Nov 2001 12:55:00 -0600
>From: "Kitzzy Aviles" < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>

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