[Mailman-Developers] Turning off dynamic JavaScript

[Laura Carlson]

--On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote:

> Are you suggesting I provide *no* link for the
> screen-reader-with-javascript client and let them at some point
> figure  out that they're not seeing what's going on and thus turn off
> javascript?
>
> That seems like a worse solution.

I'm suggesting that javascript is fine to use for progressive 
enhancement but not for core functionality. Javascript should be used 
to  enhance the usability, _if_ it doesn't negatively affect 
accessibility. A Javascript
dependent app is just not accessible.

But like it says in  6.3 of WCAG 1.0, if it is not possible to make 
pages accessible when scripts, applets, or other programmatic objects 
are turned off or not supported, the fallback is to provide equivalent 
information on an alternative accessible page.

SitePoint's JavaScript Anthology chapter on JavaScript and 
accessibility that features a lot of test results with different screen 
readers, but I don't see that as much more use than a DHTML script that 
was tested in 1999 on Netscape and IE - by making your DHTML 
accessibility dependent on the user agent - regardless of screen reader 
or browser - you make it easily outdated.

The problem is not only users of assistive technology, it is about 
availability as well. What if I work in a high security environment 
where my employer turns off JavaScript or filters it out via a proxy by 
default? What if I am somewhere without internet access on the ground 
and want to use my mobile or satellite phone to reach an app?

In both Section 508 and WCAG 1.0 a separate text only version is not 
considered an accessible solution. Basically the requirements state 
that the author has determined that the primary site CANNOT be made 
accessible, and the text only site provides some kind of second class 
access to the content.

Creating a text-only version of a web site should be done when there is 
no other way to make the content accessible, or when it offers 
significant advantages over the main version. And then the text-only 
version needs to provide the functionality equivalent to that of the 
main version.

Some thing to consider with separate versions:

Text-only versions are rarely totally equivalent in content to the 
"real" version. They often do not fully convey content and its context. 
They effectively segregate the audience they are targeted at.

When there is a text-only version available, developers sometimes do 
not make the "real" version accessible.

>From a maintenance view, creating a text-only page for every Web page 
is twice the work. Invariably, the text version is going to be out of 
sync with regular content. This then creates an accuracy problem.

The accessible version is often hidden behind its inaccessible 
counterpart. People needing to use the accessible version of the 
website still need to be able to deal with the inaccessible one. They 
have to search through an inaccessible page to find the link to the 
text-only page. This problem could be reduced by ensuring that the 
"skip to accessible version" link is the first piece of information on 
a page.

Ethan, have you considered making the main site not rely on JavaScript 
for functionality and having a link to a JavaScript enhanced version, 
so the  accessible version is not hidden behind its inaccessible 
counterpart?...Or you might want to consider this approach:

- make it work without JavaScript
- add event handlers or even an AJAX layer to make it work more smoothly
- give the user the option to use one interface or the other - as most 
web apps require login and have a defined user journey this is a lot 
easier, as visitors are not likely to enter in any of the pages like 
they do in a web site.

Best regards,
Laura

___________________________________________
Laura L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN U.S.A. 55812-3009
http://www.d.umn.edu/goto/webdesign/