E-mail List Archives

Search E-mail List Archives for

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

From: Leo Smith
Date: Tue, Aug 21 2001 7:00AM
Subject: javascript
No previous message | Next message →

Hi All..
Thanks for the very informative information regarding logical event handlers.
Concerning client-side javascript generally, reading back through some forum emails, it seems that some feel javascript to be an inaccessible entity as a user may have javascript turned off on their computer.
In my mind, if a user chooses to turn off client-side javascript capabilites on their browser, then the resulting inaccessibility of certain websites is a diffferent issue as they have made this choice and can just as easily switch the javascript back on. What do others think about this?
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).
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?
Thanks in advance for taking the time to read and respond - i know we are all very busy in our daily lives.
leo.

Leo Smith
USM Office of Publications and Marketing
207-780-4774

From: Paul Bohman
Date: Thu, Aug 23 2001 10:51PM
Subject: Re: javascript
← Previous message | Next message →

[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

From: John Farrie
Date: Thu, Aug 23 2001 11:34AM
Subject: Re: javascript
← Previous message | Next message →

> [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,
Bear in mind that someone might have had to purchase the browser/technology
that was most suitable for them, and if that set up doesn't support (or
fully support) javascript, they may not be in a position to invest in an
upgrade or purchase an alternative. People with disabilities are
discriminated against in that they don't usually qualify for the latest and
greatest free of charge. That benefit is just for the rest of us, and its
easy for us to forget that there may be cost implications.
Also bear in mind that someone might have spent a significant amount of time
or effort learning to use a particular set up. It might not be trivial for
them to change just because a different set up supports JavaScript.
John Farrie
Accessibility by Design
http://www.accessibilitybydesign.co.uk

From: Leo Smith
Date: Fri, Aug 24 2001 7:57AM
Subject: Re: JavaScript
← Previous message | Next message →

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.
Best,
Leo.

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
207-780-4774

From: Cohen, Lisa A.
Date: Fri, Aug 24 2001 8:49PM
Subject: Re: JavaScript
← Previous message | No next message

Leo,

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.

Thanks,
Lisa