WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JavaScript


From: Cohen, Lisa A.
Date: Aug 24, 2001 8:49PM


I also find the Section 508 position on JavaScript to be a bit fuzzy.

Since paragraph "L" specifies that "the information provided by the script shall be identified with functional text that can be read by assisitive technology"
.... and ....
the WAI WCAG specifies that websites shall run with Javascript turned off as a Priority 1 guideline

... and ...

(back to the Section 508 Final Rule)
the Note (2) to 1194.22 says that "Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section."

... and ...

elsewhere in the Section 508 Final Rule it seems to say only that the requirements borrow from the work done by the W3C,

I find myself asking questions like, Why is the Access Board's requirement less restrictive than the WAI WCAG guideline?
and, Does the Access Board assume that more assistive technologies will quickly "catch up" and work well with Javascript?

I have not been able to do much testing within the assistive technologies yet, but I did work briefly with a demo version of JAWS on one of our developing websites. I was having some trouble learning the JAWS navigation keys... but, the two things that stuck out to me were that a table which was coded EXACTLY like the example given in the WAI techniques was not read correctly by JAWS; and, the Javascript alert messages were interpreted perfectly by JAWS.

I would be interested to hear others thoughts about Section 508 vs. WAI WCAG on javascript.


-----Original Message-----
From: Leo Smith [mailto: <EMAIL REMOVED> ]
Sent: Friday, August 24, 2001 9:54 AM
To: WebAIM forum
Subject: RE: JavaScript

Paul and John..

Thanks so much for the feedback and input. As I do not work directly with assistive technologies, sometimes it is hard for me to gauge the implications of the javascript issue. However, this fall I plan on spending some time observing in an assistive technology lab, so hopefully can begin to gain first-hand a better understanding of the issues.

One of the reasons for my questions concerning JavaScript and accessibility centers around the Netscape re-size fix that Dreamweaver includes.

This JavaScript fix ensures that when layers (or DIVS or absolute positioning) are used in Netscape 4, that they remain stable when the browser window is resized.

I have used DIVS on some sites, and have found them to be completely stable across IE4, IE5, IE5.5, NS6, and NS4 when the resize fix is included in the code. I guess layers in NS4 "fall apart" when the browser is resized, and this fix essentially forces the page to reload in this browser when a resizing occurs, thus retaining the pages correct layout.

This was the issue I was thinking of when I wrote "sometimes client-side JavaScript may be needed for an essential feature (for example the Netscape resize fix for layers that dreamweaver provides). As long as such JavaScript isn't doing anything that someone with an impairment will miss out on, is it really inaccessible?"

I understand that this would be inaccessible to those who have Javascript turned off or whose browser does not support it, and would thus violate one of the W3C Priority One specifications.

But, I think that the question arose more from reading the 508 guidelines, which do not seem to specify that a page has to function without JavaScript, just that any functionality that JS provides should be accessible. (I am a little cloudy as to what specification "L" in the 508 fully implies). The re-size fix only exists in the background as a satety net if someone happens to resize their NS4 browser. It is not providing any extra functionality unless the browser is resized. If the NS4 browser window cannot be resized by a user with an impairment, that would be an issue of the software not being accessible, and wouldn't be an issue involving this JS code. What do others think about that?

I guess the reason I bring it up is that I am very enthusiastic to use absolute positioning, if not to completely replace tables, to certainly reduce the amount of nested table coding that is often needed to achieve complex layout. I tend to use tables within DIVS for structure, but with the DIV, I can specify exactly on the page where I want the table to be with very little code, rather then having to create an elaborate nesting table effect to achieve that same positioning of the table.

Would love to hear what other folks think about this issue.



On 23 Aug 2001, at 10:48, Paul Bohman wrote:

> [Leo] In my mind, if a user chooses to turn off client-side JavaScript
> capabilities on their browser, then the resulting inaccessibility of
> certain websites is a different issue as they have made this choice
> and can just as easily switch the JavaScript back on. What do others
> think about this?
> [Paul] I tend to agree with you on this one, at least in principle.
> The reality is not quite so cut-and-dried though. Sometimes, the best
> browser for a particular person for a particular disability is a
> browser which doesn't support JavaScript, or which only supports it
> partially. This usually doesn't mean that the person absolutely MUST
> use this other browser, but it means that it is BEST for this
> particular individual. If this person wants, he or she could use a
> different browser, and turn the JavaScript on, but that would be a
> second-best solution. So, although I agree in principle, the reality
> of the matter is that I can't always say that they have JavaScript
> disabled just because they want to. With this in mind, whenever using
> JavaScript, I recommend always providing an alternative method to
> achieve the same functionality.
> [Leo] In my mind, what is important in terms of making a website
> accessible to those with an impairment is making sure that any
> functionality provided by client-side JavaScript is also accessible to
> these users. I think the use of logical event handlers can solve a lot
> of these issues (maybe even the dhtml drop down menu problem - if the
> menus can be opened by the keyboard, the contents of each menu can be
> read by a screen reader, and the link opening the menu is described to
> indicate that this is what is does).
> [Paul] Again, I agree, in principle. Your logic is not flawed, but the
> technologies are, unfortunately. Assistive technologies, JavaScript,
> and browsers do not yet work as well together as we'd like them to.
> Sometimes these functionalities can be achieved, but not all of the
> time. The testing and debugging process of producing
> disability-accessible DHTML JavaScripts is oftentimes not worth the
> effort. It would be a good project to undertake, though, for someone
> who has the time and skill (and who is willing to share the results
> with us!).
> [Leo] I like the idea of designing pages without JavaScript, and then
> including any at the end of the design process for "non-essential
> features." However, sometimes client-side JavaScript may be needed for
> an essential feature (for example the Netscape resize fix for layers
> that dreamweaver provides). As long as such JavaScript isn't doing
> anything that someone with an impairment will miss out on, is it
> really inaccessible?
> [Paul] I think you mean to ask "is it really that bad." The answer to
> your literal question ("is it really inaccessible") is "yes", of
> course it is inaccessible to those who have JavaScript disabled (or to
> those who cannot use a mouse with mouse-dependent JavaScripts, etc.).
> But is that bad? It all depends on what it is that is inaccessible. If
> the content is important, then it's inaccessibility would be a
> problem. That would be bad. If the content is not important, then the
> fact that it is inaccessible is irrelevant. I know this sounds
> simplistic, but this is a judgment that the content's author has to
> make.
> Perhaps someday client-side scripting (e.g. JavaScript) will work well
> with all of the major assistive technologies and browsers. At that
> point, I will feel comfortable putting my efforts into making the
> scripting directly accessible, without worrying about a non-scripted
> alternative. Until then, I will continue to provide an alternative.
> Paul Bohman
> Technology Coordinator
> WebAIM (Web Accessibility in Mind)
> www.webaim.org
> Utah State University
> www.usu.edu

Leo Smith
USM Office of Publications and Marketing