W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > October to December 2001

Re: Combining Server/Client-side techniques for accessibility

From: Carlos A Velasco <velasco@fit.fraunhofer.de>
Date: Sun, 21 Oct 2001 20:05:30 +0200
Message-ID: <3BD30E6A.2020106@fit.fraunhofer.de>
To: Chuck Letourneau <cpl@starlingweb.com>
Cc: w3c-wai-eo@w3.org
Hi Chuck, all,

First, another argument for those that complain about server load when 
using server-side scripting: client-side scripting also requires to 
serve bigger pages, because you must send a few Kbs of JavaScript to the 
client (and I have seen pages with more than a few Kbs, but close to 
50kbs of extra JavaScript code due to complex validation form techniques).

As already said, browser sniffing will not work, because you are not 
able to determine from the HTTP request whether the user has JavaScript 
activated. Therefore, the only "reasonable" technique, also from an 
accessibility standpoint, is server-side scripting. If you are receiving 
100,000 requests a day, you better have a good server with load 
balancing, otherwise you are in big trouble.

In regard to the solution that Judy wants to implement for the document 
we were discussing, the solution we use is X(HT)ML+XSLT (Apache + 
Cocoon). But I do not know which server is W3C using. But I am sure, 
Charles does <grin />


Chuck Letourneau wrote:

> Hi All,
> I broached this during today's discussion of techniques for in-page 
> expansion of detail in the "Implementation Plan for Web Accessibility" 
> document.  I have provided slightly more than the one or two lines of 
> explanation that Judy requested.  Sorry about this <grin>.
> Many of us believe that server-side scripting makes dynamic or 
> interactive pages more accessible than pages using corresponding 
> client-side techniques.  Oft-heard excuses for the "requirement" for 
> client-side processing - e.g. for form validation, dynamic layout and 
> content, etc. - instead of server-side processing are that "our server 
> can't handle the transaction load" or that "the response time for 
> clients would be unreasonable".  Since it is sometimes difficult to 
> create the equivalent functionality of client-side features in 
> non-scripted HTML I suggest the following "solution":
> Why not design the scripted functionality with client-side techniques 
> that will be used by the vast majority of visitors to the site (i.e. 
> those whose user agents do support and who can access client-side 
> services).  Then, instead of making the accessible "fall-back" a 
> non-scripted alternative, make it a call to an equivalent server-side 
> script.  This means that the majority of users will process the service 
> locally - putting no further strain on the server - and only the 
> relative few who won't or can't support scripting will cause a further 
> transaction on the server.
> I don't have any statistics handy, but for sake of argument I'll guess 
> that 5% of the browsing public can't or won't support client-side 
> scripting.  If a page gets 100000 hits per day, 95000 would be processed 
> on client-side and only 5000 would issue another hit on the server.  I 
> would be surprised that anyone expecting a high transaction volume would 
> not have at least 5% extra capacity on their server.  For the end-user 
> who needs the server-side version there might be some slight reduction 
> in transaction speed but I suspect that the slight speed drop would be 
> mitigated by the fact that the functionality is available at all.  
> Turned the other way, the organization benefits from making the page or 
> service accessible to users of more types of user agents.
> By the way, please don't ask me to provide you with a real example of 
> this suggestion.  I don't have one.  I would be really happy if someone 
> who is knowledgeable in both server- and client-side programming 
> techniques could try this and report back to us (and probably the WCAG 
> group).  Maybe one of you knows of a live example and could point us to 
> it.  I have based this suggestion on the word of some technical folk who 
> thought that "this should be possible".
> Regards,
> Chuck Letourneau

Dr Carlos A Velasco
mailto:velasco@fit.fraunhofer.de    http://access.gmd.de/
Fraunhofer-Institut für Angewandte Informationstechnik (FIT.HEB)
   [Fraunhofer Institute for Applied Information Technology (FIT.HEB)]
   Schloss Birlinghoven, D53757 Sankt Augustin (Germany)
   Tel: +49-2241-142609/319272 Fax: +49-2241-142065
Received on Sunday, 21 October 2001 14:09:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:29:32 UTC