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

[eo dropped, will post them a pointer.]

1.  Scope/venue:  The process for negotiating where the processing gets done,
where there is an option, is a Device Independence topic; and PF is their
principal [i.e. first and central, not sole] point of contact in WAI.  This is
a negotiation protocol.  Not to say PF don't want to share the search for a
solution. but by the charters "who WAI.Domain should refer
W3C/Device_Indepenedence to on first being asked on this point" is WAI-PF.

2.  Yes, yes, yes.  The Content rule is to target the content for a range of
service options, an "any function can be done anywhere, modulo bonafide
dependencies are satisfied" service-option diversity.  Note that in the Device
Independence Working Group we have a group of participants dominated by the
scenario where the default is that the server does the adaptation to final
form
for a thin client, and offering the option of serving a flexible document to a
thick client where required for unanticipated user requirements is [part of]
what we are arguing for as access accomodation. 

So the scenarios arising from the content-sourcing community are split with
some posing the risk that the client-side default turns into a requirement
because the requirement to support the option was not asserted, and some where
the default is  server-side and again there is the risk that the default turn
into a sticky wicket. 

Note that the basic "any function can be performed anywhere, modulo
satisfaction of bonafide dependencies" is a policy I am working on getting
adopted as part of a "minimalist view of grid architecture" in the Global Grid
Forum, a group who are customers of Web Services with high quality of
end-to-end service requirements just as we have high requirements.  For
more on
the GGF relevance, see:

 <http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Sep/att-0018/01-Oct
2001.html>http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Sep/att-001
8/01-Oct2001.html

See also the following discussion of serving access evaluation reports for
another example of how the Device Independence practices fit into the overall
flow of the web:

<http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Oct/0054.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-er-ig/2001Oct/0054.html

For your information, there is also a scenario where the client takes over
structuring the dialog.  The server serves the schema for the DI resource base
and business rules and the client sends XML Queries complying with the
business
rules and retrieving suitable composite samples from the DI resource base with
which to populate an interaction world that it has created, adapted
specifically for this user.  [Haven't told DI of this, yet, though.]  In the
out years, this superClient for individuals with multiple and severe
disabilities will draw on independent accesses to Web Services that the first
'retail' service didn't think about.

"Out years" in this case is no later than Mike May's GPS enabled BrailleNote
hits the market, in the best-case scenario.  I owe y'all a public copy of that
scenario.  But it gets the blind or wheelchair using pedestrian information
about sidewalk closings and bad crossings that isn't in the commodity
restaurant guide.  The consumer accesses the commodity restaurant guide and
the
DPW sidewalk closings database that construction contractors and PWDs all use
and combines the information with the aid of schemas that most clients don't
bother with.  That's the gist.  More on this when I get there will go to EO.

Al

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 13:22:24 UTC