Re: FW: Combining Server/Client-side techniques for accessibility

I responded once to this post on GL.  

The basic idea is "yes, there should be some diversity in where things get
done, and it is necessary to get this instilled in the DI principles to
make it
W3C dogma, because it is generic DI stuff and not peculiar to disability
access.

 http://lists.w3.org/Archives/Public/w3c-wai-gl/2001OctDec/0136.html

In particular, In that post I briefly mention a scenario dealing with "how
PWDs
oughta be able to use the Web of Web Services soon."

This one revolves around the Mike May GPS-enabled BrailleNote personal digital
assistant.

The scenario is that the BrailleNote uses its GPS accessory to know where the
user is in the city and they use the built in browser and radio internet
access
to access a commodity restaurant guide site.

First off, there is a machine shortcut by which "here" becomes something
out of
the GPS service that the user can inject into the query against the restaurant
guide where it asks "near where?"  [This can be done if the restaurant site
uses XForms, so that there is a defined (and accessible?) model of the
user-input fields by which it asks about map locations.]

Secondly, the route-planning function in the BrailleNote knows through user
customization that it cares about sidewalk closings and bad intersections with
short lights or inadequate crosswalk marking.  The restaurant guide doesn't
understand this level of stuff and doesn't need to.  It just includes a street
address, and the GPS route-planner goes from there.  There is an
interoperation
standard for plugins that means the GPS route-planner as shipped didn't know
about the DPW (that's Department of Public Works for international readers)
sidewalk-closing service, but the user can install knowledge which tells the
route planner how to access the DPW service.  This may all be discoverable. 
The user on web-browsing to the DPW site could be able to pick up WSDL for the
sidewalk-closings service and the browser knows how to disclose this to the
pedestrian-route-planning GPS plugin service and we are off on a route that
avoids the construction horses across the sidewalk.

This is client-side combination of information from un-cooperating servers,
for
which we need access to metadata from each un-cooperating server to build the
metdata bridge so we can join the information from the several formats used by
the several servers.  This is the radical step.  It doesn't require RDF.  RDF
can be instrumental in making it easy.  It requires that all the sites accept
an "only document" level of metadata standard.  Then third-party WebServices
can do the connecting from there to make composite data [see Grossman]
available as a resource to client-hosted methods.

Al

[Grossman]  See Bob Grossman's entertaining pitch including "W's law" about
"data is interesting in proportion to the square of the column count in the
joined table."

 Alliance All-Hands PowerPoint Presentations
 <http://fantasia.ncsa.uiuc.edu/media/2001Meeting>http://fantasia.ncsa.uiuc
.edu/media/2001Meeting/

Google for "Mike May GPS BrailleNote" for more on the device development
program.

At 06:14 AM 2001-10-21 , bill@eramp.com wrote:
>
>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
> 
>        <http://www.eramp.com/>www.eramp.com
>
>
>
>-----Original Message-----
>From: w3c-wai-eo-request@w3.org
[<mailto:w3c-wai-eo-request@w3.org%5DOn>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 20:27:09 UTC