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

Combining Server/Client-side techniques for accessibility

From: Chuck Letourneau <cpl@starlingweb.com>
Date: Fri, 19 Oct 2001 10:28:14 -0400
Message-Id: <4.2.2.20011019092328.00a53a10@host.igs.net>
To: w3c-wai-eo@w3.org
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
Received on Friday, 19 October 2001 10:28:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:49 UTC