Re: Combining Server/Client-side techniques for accessibility

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

Browser Sniffing? this is an impossibility, there are no mechanisms (until
(if) CC/PP becomes available) the HTTP_USERAGENT is not appropriate for
this.  As you seem to be suggesting ASP, then hopefully by now the
relevant Microsoft Knowledge Base Articles have added a disclaimer that
this doesn't work even for "standard" browsers, let alone issues like
browser configuration (no images, no script etc. etc.) or Accessibility
technology based on top of them.  For example Jaws for Windows, makes
IE5.5's capabilities radically different.

> 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.

The majority of uses for client-side scripting either already have server
duplication (form validation), or are not duplicatable in the server
(popup menus, rollovers, etc. etc.)

> 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).

Just about every form, on any page has form validation with server side
validation aswell as client (if it doesn't then the server has a
problem...)

Jim.

Received on Sunday, 21 October 2001 13:14:15 UTC