RE: Client Side vs. Server Side Image Maps

At 07:00 AM 2002-02-02 , Nick Kew wrote:
>On Fri, 1 Feb 2002, Al Gilman wrote:
>
>> Yes, it is important to recognize that this case exists, where the function
is
>> a genuine continuous-parameter function.  Map sites are a staple of web
usage
>> today.
>
>And indeed for several years: my own 1995 work at ESA offering a
>query interface to order satellite data remains unchanged today.
>Manipulating geographic data was probably also the first application in
>which we saw a range of sensible applications of JAVA on the client side.
>
>> There is a collection of techniques that could relate here.
>>
>> 1. The notion that the (0.0) coordinate value in a map request should be
>> treated as potentially a request for a pointerless access mode.
>
>I have to disagree with this.  Even if we can rely on browsers supporting
>submission-with-(0,0), it is totally counterintuitive for users to
>think "I can't use this map, so I'll submit it anyway".  Any alternative
>solution must be presented *before* this point!
>

AG::

How can I explain this?  I think I believe in all the positive things you
affirm: that putting the first FORM of a keyboard-friendly dialog on the same
page with the image that serves as the visible content of a server-side
map-lookup service is _better_.  Maybe it is required.  But it is not enough.

I tried to say that in the second paragraph of my point number 3, to wit

>
> This does not mean that the keyboard accessible dialog should not be started
> right on the page alongside the map, as Nick suggests.  It just means that
> server side maps should always have a (0,0) response and it should always
> cover the possibility that the user is keyboard-only.  This response does not
> have to assume the (0,0) coordinate value is a conventional signal, but it
> should cope with that possibility.



However, I don't believe that this means you have to oppose the incorporation
of a safety thread in the server-side-image-map object itself.

We can't limit our safety net to covering only the _more rational_ user
behavior.  User behavior will vary, and we have to catch and deal gracefully
with both cases, here, as I see it.

User behavior is just not that predictable.  It is a cliche of user interfaces
and user support that seniors are risk averse as regards on screen commands and
want to have read through a description of the whole process before taking the
first step, whereas their grandchildren never crack a manual but poke
everything that seems to be manipulable and learn the system interactively by
this kind of exploration of what it does.

What made the Web go initially included the fact that following hyperlinks was
amenable to 'undo.'  The standards for activating active elements in web pages
are like that.  You should be told what to expect, but as experience designers
we can't assume that elements will only be activated on that condition.

And what we can expect authors to actually follow, in terms of what comes
before the image map in the tab order, is rather limited.  It is really the ALT
on the image itself.  If this could contain a hyperlink to the FORM equivalent
on the same page, then we might relax this demand on what the initial value of
the pointer coordinates [what the browser sends if you TAB to the image map and
then activate with ENTER] returns in the way of a server response.  For the
case where the author had provided an in the same page alternative with a
hyperlink to it.  All the reasoning in the current thread about parallel sites
in the WCAG group applies to parallels to server side image maps.

<http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/thread.html#251>
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/thread.html#251

But as it is, I believe we should handle the case that the image map appears
before the FORM in the tabbing order of the page, and we should expect the
server process to handle gracefully the case that the user without a pointing
device TABs to the image map and activates it forthwith.

I want to remind people of some things I believe I learned from working with
Gregory.  The first is an image that evokes just how narrow is the speech
user's field of view within the current page.  He likened the experience of
wandering the web with speech to spelunking; slithering through dark crevices
under the earth, moving from handhold to handhold.

In modern theory of organizational behavior, such as is reflected in the
_Virtual Teams_ book by Lipnack and Stamps, one learns that it is important to
resolve matters as locally, at the lowest level, that one can.  This is why
individual sales clerks are given some latitude to handle customer complaints
and only if they cannot satisfy the customer is the customer referred to the
customer service (that is, the people who say 'no') desk.  User interfaces have
to honor this principle also.

Early Web authoring concepts likened a website to a building and each page to a
room.  We have to realize that for the visitor operating in speech, the tools
of intrapage orientation are experimental at this time, and rather than an open
room, each page is a maze and exploratorium for the visitor arriving in speech
mode.

There is a cartoon in this week's New Yorker which depicts rats arriving at the
gala opening of a rat art show.  The joke is that the art is all displayed in a
maze.  But this is a fit metaphor for screen reader users coming to your page.

This is the background, the climate of beliefs about what we can achieve in
terms of an adapted web wandering experience for screen reader users, that
informs my feeling that we have to have an approach to the case that the user
wants to poke the server-side-image map as a whole, and not wait to find the
"text links at the foot" equivalent somewhere.

To cover this contingency, server-side image maps service processes should
provide some sort of root response, for which the (0,0) response seems to be a
reasonable, and the backward-compatible definition, which meets home-page-like
requirements to incorporate "help" and "alternatives" paths within itself.

That last is a little strong.  It is simply where my beliefs are at at the
moment, based on what I have seen in the past.

But I do want to introduce a little daylight, an arm's length, between the
virtue of the on-the-same-page keyboard-friendly-dialog-start and the
consumer-safe implementation of server side image maps themselves.  For the
speech visitor, "on the same page" is still off-screen when the user is at the
image map as they tab through, which in all likelihood will come first, and
will in all cases be "may come sometimes."

I probably should have put the recommendations in more top-down order:

1. Server should have a keyboard-friendly process to deliver an equivalent
service.

2. Site should expose the keyboard-friendly process by at minimum one text link
on the same page with the server side image map.  Better the first-step form.

3. Map request handler should serve a (0,0) response which also contains this
[link or better, initiation of keyboard-friendly dialog by forward motion from
there].

4. User agent should send (0.0) in case of focus+activate, as when the user
arrives at the image map by tabbing and then activates by ENTER.

[5. XHTML 2.0 should look at ways to provide a navigable association with
keyboard-friendly alternative from image-map hypertext structure used with
server-side image maps]

Is any of that counter-productive?  Plese distinguish 'counter-productive' (at
the user with service interface) from 'unnecessary' which may indeed be
counter-productive (at the author with guidelines interface).

Al

>
>-- 
>Nick Kew
>
>Site Valet - the mark of Quality on the Web.
><URL:<http://valet.webthing.com/>http://valet.webthing.com/>
>

Received on Saturday, 2 February 2002 10:47:35 UTC