--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/