FW: Combining Server/Client-side techniques for accessibility

I agree with Chuck's solution. Defaulting to client processing but 
providing "slide-ability" of that functionality up to the server when necessary 
can (depending on the script) often be as simple as combining browser sniffing 
with the addition of a single directive within the script tag. To use an Active 
Server Page (ASP)example:

<SCRIPT RUNAT="Server"> will run the script on the server, where <Script> will 
default to the client. An "if" statement based on the result of a browser 
sniffing test can add/don't add the additional attribute. 

Of course, the script itself will need to be written with the consideration 
that it could run in either environments. 

As an example requested, the Microsoft site provides this type of functionality 
in its toolbar (or at least use to, I haven't checked it out lately). 

 
Bill Shackleton 

=========================
 
Access Empowers People...
       ...Barriers Disable Them
 
        www.eramp.com



-----Original Message-----
From: w3c-wai-eo-request@w3.org [mailto:w3c-wai-eo-request@w3.org]On
Behalf Of Chuck Letourneau
Sent: October 19, 2001 10:28 AM
To: w3c-wai-eo@w3.org
Subject: Combining Server/Client-side techniques for accessibility


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 Sunday, 21 October 2001 10:14:51 UTC