This article was written many years ago, before AJAX became a buzzword and any of the JavaScript libraries such as Prototype, jQuery or Mootools had sprung up. Originally, this was an email that I sent to some co-workers, explaining to them why (at the time) we couldn’t make our web app work like a desktop application. Today, of course, we can achieve so much more, but the fact remains that you cannot rely on client-side scripting alone to process data or to be compliant with Section 508 and other accessibility guidelines.

In a Nutshell

Web applications cannot perform client-side processing and still be compliant with Section 508 and other accessibility guidelines.

Long Explanation

Client/Server applications are “rich clients,” in that they allow for more complex graphical user interfaces and the use of client-side processing. COM, DCOM and Active X all allow client-side processing in a Microsoft environment. The limitation of the Client/Server approach is that they can only reach to highest level of where the application is hosted.

Web applications are a low-cost, broad-reach approach that provide access to information and applications from wherever the user is located. Unlike Client/Server apps, Web apps are “thin clients.” The drawback is that Web apps limit the user experience by turning the client computers into “dumb” terminals. Web applications cannot perform client-side processing, and still be compliant with Section 508 and other accessibility guidelines. Data must be transferred to the server via an HTTP request, so elements of the Client/Server user experience are lost. Examples include direct manipulation of data, such as dragging and dropping elements and client side-processing and storing data locally.

It is, however, possible to perform many of these functions with Javascript, which operates on the client. Sorting, filtering and validation can be done easily. Database calls can be made, but in a more complex method called Remote Scripting, which still relies on Javascript. However, this would violate accessibility requirements, and support would be sketchy at best

[1].

Guideline L of Section 508, Subsection 1194.22 states: “Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used.[2]”

Many public sector clients also require their Web applications to adhere to the W3C’s Web Content Accessibility Guidelines. Guideline 6, Checkpoint 6.3 states: “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.[3]”

On top of the accessibility guidelines, it is a best practice in Web development to ensure that any client-side scripts are accompanied by server-side scripts that perform the same functionality. This is because, in any Web browser, the user has the option to turn off Javascript. Futher complicating the issue, some assistive technologies and Web-enabled appliances do not even support Javascript.

The conclusion is that Web applications cannot reliably perform client-side scripting in the same fashion that Client/Server applications do.

Primary Resources

Other Resources