Re: Section 508 Question on Javascript - Section 1194.22, Paragraph (l)

Just a note about the javascript menus which you mentioned (

There are many sites which use similar javascripts. One of the main reasons
that these are inaccessible to screen readers and those who do not use a
mouse is that the menus only come down when the "onMouseOver" event is

The menus are completely invisible and unusable to someone who tabs to the
links. The only way to get around this would be to provide triggers that
work with both a keyboard event and a mouse event.

A similar discussion on this same topic was held several months ago. From
what I remember, the basic conclusion was that currently there are innate
deficiencies in the javascript language that do not permit keyboard input
with the same sort of efficiency or reliability as with mouse input.
Following this, a lengthy, circuitous, philosophical debate ensued regarding
the equivalency of the "onMouseOver" concept and the "onFocus" trigger.

The basic concept is simple: javascript should not be written to require
mouse input--it should also accomodate keyboard input. The reality of the
matter, however, has not turned out to be as simple, because--as was
mentioned in the past debates on this topic--there are good reasons to
differentiate between mouse events and keyboard events with regard to the

As far as I can tell, javascript is still not mature enough of a language to
accomodate non-mouse users very well. The capabilities of the langauge are
just too limited.

My own personal, less-than-ideal conclusion: Until javascript matures, go
ahead and use the onMouseOver menus as long as the same menu structure is
available in a redundant text format.

Another possible solution: Maybe it would be possible for screen readers
(e.g. Jaws, Home Page Reader) to develop somewhat "intelligent" algorithms
that decipher the javascript in such a way that the screen reader reads the
textual contents of onMouseOver events, despite the fact that the command is
never actually triggered by a mouse. The screen reader could interpret a
"tab-to" as a "onMouseOver" if it wants to. Actually, this seems do-able to
me. What do you think, Jim, or others?

Paul Bohman
Technology Coordinator
Web Accessibility in Mind (
at the Center for Persons with Disabilities (
at Utah State University (

----- Original Message -----
From: "Jim Thatcher" <>
To: "Fitzgerald, Jimmie" <>;
Sent: Wednesday, February 14, 2001 8:55 AM
Subject: RE: Section 508 Question on Javascript - Section 1194.22, Paragraph

> I too have been trying [1] to find examples of inaccessible JavaScript - I
> would like to know about things JavaScript writers should NOT do.
> The author of the JavaScript menus on has told me he considers
> those to be inaccessible. Indeed they appear as non-links for HPR and for
> JFW. But because there is equivalent facilitation, including a text only
> site, this is not an accessibility issue; in fact the site works fine with
> JavaScript turned off or inadequate as in Netscape 4.x (they want their
> to meet WCAG 6.3).
> What we need is a catalog of JavaScript techniques that are NOT accessible
> (or yield inaccessible sites) as well as those that are. These would be
> like programming strategies than the techniques we usually talk about for
> static HTML.
> I proposed one in [1], "don't use onChange in select menus,"  but since
> Doug Wakefield pointed out to me that if you use keyboard access
> 'correctly,' starting with Alt+Down Arrow, in a select menu (combo box)
> onChange is not a problem!
> Here is another proposal.
> ** JavaScript menus do not meet the accessibility criteria of Section 508.
> Even if the links are available to (some) assistive technology (as at
> the structure of the menus is lost. If you use
> dropdown menus to facilitate navigation, be sure that the corresponding
> links are immediately available to those who cannot access those menus,
> in the navigation panel of the target of the each main menu item.
> You see, this is a modified WCAG idea; I want it to say that as far as the
> JavaScript menus are concerned, your site has to work well with JavaScript
> turned off. It does not say that your whole site has to work with
> turned off.
> [1]
> Jim
> Accessibility Consulting
> 512-306-0931
> -----Original Message-----
> From: []On
> Behalf Of Fitzgerald, Jimmie
> Sent: Wednesday, February 14, 2001 8:33 AM
> To:
> Subject: RE: Section 508 Question on Javascript - Section 1194.22,
> Paragraph (l)
> As I've said before, we are more concerned here with 508 than we are with
> WAI from the W3C.  With that in mind...
> Does anyone have a page/site/snippet of code demonstrating JavaScript or
> VBScript for accessibility?
> I'd like to see a page with DHTML writing some dynamically created content
> with a script and an explanation of how and why that isn't accessible.
> then like to see the same page made accessible without sacrificing the
> portion of it.  If that can be done.
> I've seen lots of talk about this and the 508 is not clear on it at all
> I've not seen anyone post url's to examples or anything like that.  Maybe
> just missed it?
> I am all for accessibility but unless I can see some hard evidence related
> to script issues such as the one I am asking for here, I'll be inclined to
> continue scripting my little heart out.  I suppose I am failing to get the
> point on why Lynx or Script-less browsers are considered in the arena of
> ADA.  American Disabilies Act right?  Not BDA (Browser Disability Act).
> Sorry if I sound a little insensitive here, not trying to be.  Just
> on all this talk about browsers.  Aren't we trying and really only trying
> make sites accessible to *people* with disabilities?  Thought I had a clue
> about all this last week and this week, I am feeling pretty stupid about
> all.
> Jim Fitzgerald
> -----Original Message-----
> From: Gregg Vanderheiden []
> Sent: Wednesday, February 14, 2001 9:00 AM
> To:
> Subject: RE: Section 508 Question on Javascript - Section 1194.22,
> Paragraph (l)
> Hi Graham
> Here is the answer from Doug Wakefield at the Access Board  who put the
> regulations together
> With his permission I am reposting here  and on the SEC508 list
> Gregg
> Hello Gregg,
> In response to the question on the list concerning functional text in
> scripts:
> When a script has no associated text or label, the screen reader often
> some content of the script itself in a jumble of letters and words. We
> chosen not to forbid the use of scripts, by rather to require that script
> functions provide text that will accurately tell a user the purpose of the
> script or action.
> Although there are some event handlers in JavaScript's that can pose some
> tricky access problems, the bigger problem is the manner in which scripts
> write to the screen.
> Doug Wakefield
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
> Professor - Human Factors
> Depts of Ind. and Biomed. Engr. - U of Wis.
> Director - Trace R & D Center
> FAX 608/262-8848
> For a list of our listserves send "lists" to
>  -----Original Message-----
> From: []  On
> Behalf Of Graham Oliver
> Sent: Monday, February 12, 2001 2:56 PM
> To:
> Subject: Section 508 Question on Javascript - Section 1194.22,
> Paragraph (l)
> Hi
> I have tried to get to some sort of understanding of
> this on the Section 508 list at Trace, but am still in
> the land of confusion!
> The thread starts here
> I have been asked to write an article on accessibility
> which covers Section 508 so would like to give a
> reasonable interpretation of this regulation.
> Anyone care to have a go?
> Cheers
> Graham Oliver
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year!

Received on Wednesday, 14 February 2001 13:30:27 UTC