Re: ISMAP-class problem with script

to follow up on what Jon Gunderson said:

> Instead of an ISMAP view of looking for mouse positions, the author could
> have associated IDs with each of the images.  The event handler could get
> the ID of the object and know which of the images was clicked on without
> needing to compare mouse coordinates with image coordinates (although the
> later could also be done).  
> 
> One way to partically identify elements that respond to events is to
> require that they define the ID attribute.   But, IDs can also be used to
> manipulate an element in response to another elements reponse to a DHTML
> event, so this is not necessarily a definitive identification that the
> element responds to an event.
> 
> Does this make sense?
> 

In general, I think you are barking up the right tree, in terms
of putting features in the DOM to know which objects in the
document are active, and beyond that what kinds of things they
are liable to do.  In particular, I don't see the ID as the right
limb of the tree to be barking up, so to speak.

If I understand the way a script can access the DOM, every
element in the document, whether it declares an ID or not, is
vulnerable to being rewritten.  A benign script could walk the
document in the DOM and linearize any TABLE elements it found.  A
mischievous script could walk a document and ROT13 obscure every
ALT attribute it found.  At least at present, by the time the
document is in the DOM, every node has a DOM identity and is
accessible by walking the structure.

The fact that an element has a NAME or ID in the hypertext means
that other things in the hypertext can refer to it.  It is not
necessary to declare an ID for an element to be an active
object, or the [English grammar-] object of the action taken
by another element.

Because there are existing uses for IDs in passive applications,
I would not want to overload "has an ID" with the required
connotation "takes a role in actions."

Note: in the case I wrote up more or less as Chuck described it,
if you were to query the ID of the image in one of the cells, it
might not tell you it had an "on mouse down" event happen,
because the HTML does not declare an event handler for that
event.  Maybe in the implementation, all possible events are
always computed, but I can also see the case where the mouse
coordinates are checked against the sensitive outline for the
_entire table_ to recognize that a handler needs to be fired, and
then the event handler for the table takes control and _goes back
and queries the environment for the mouse coordinates_, in a way
outside the monitoring for declared event conditions.

In the scenario as described, what the table event handler does
with the mouse coordinates is private to the event handler.  It
is not made public that it just compares the mouse coordinates
with a simple list of disjoint regions like a sensitive map and
generates one of a short list of outcomes as a result.  It is
just a possible to programmatically generate a gradual response
to the mouse coordinates, as with the little pair-of-eyes widget
that helps you find the cursor on the screen.

The "yes" part of my answer would be that it is important to know
what the scripts might do, and how one triggers each in the GUI,
and how one can redirect the activation-input of each method to
some other channel.  That channel should be supported by enough
display information so that things the user needs to decide
(perhaps forking a new process) are adequately explained in
advance and the inteface is predictable.

> Jon
> 
> 
> At 03:40 PM 10/3/98 -0400, Al Gilman wrote:
> >Chuck described a problem event-handling script for us in the
> >User Agent telecon a week or so ago.  As I understood the 
> >scenario, it is "the same class of object as the deprecated
> >server-side sensitive image map."
> >
> >I want to build on this analogy in our WAI-PF dialog with the
> >DOM group about accessibility requirements.  But I owe the
> >example to Chuck and that meeting, so I am writing it down
> >here first.
> >
> >There is a table.  in the table cells there are images.  There is
> >no on-mouse-down event handler bound to any of the images, but
> >there is one on the table.  The script which handles
> >on-mouse-down for the table, however, inspects the current mouse
> >location to decide what to do.
> >
> >To perfect the ISMAP analogy, let us just say that it compares
> >the mouse position with a disjoint set of rectangles falling
> >entirely within the table and each one completely enclosing one
> >image.  This is a control morphology identical to a sensitive
> >map.  Now, we have established accessibility standards that say a
> >sensitive map should be done on the user side because then the
> >user agent can give the user verbal information about the
> >available control actions and their prospective outcomes.  In a
> >sense, the DOM question is "Is the DOM a frame of reference where
> >we can recognize that this is the same thing as the server-side
> >image map pathology?"
> >
> >Jon has done a good job in his note about "DHTML Issues"
> >that this is the basic usability/accessibility problem:
> >how can the user have adequate visibility over the potential
> >consequences of actions so that the UI merits being rated
> >as "exhibiting predictable response?"
> >
> >To the user, the on-mouse-down handler is a method associated
> >with an object, the table.  I suspect that DOM 1 only covers the
> >information associated with the table that the HTML tells us, not
> >the behavior of its methods that the script tells us.
> >
> >When and how to get the model to cover and discipline what
> >actually bites the user is one of the things that WAI-PF
> >and the DOM WG need to discuss.
> >
> >Al
> > 
> Jon Gunderson, Ph.D., ATP
> Coordinator of Assistive Communication and Information Technology
> Division of Rehabilitation - Education Services
> University of Illinois at Urbana/Champaign
> 1207 S. Oak Street
> Champaign, IL 61820
> 
> Voice: 217-244-5870
> Fax: 217-333-0248
> E-mail: jongund@uiuc.edu
> WWW:	http://www.staff.uiuc.edu/~jongund
> 	http://www.als.uiuc.edu/InfoTechAccess
>

Received on Monday, 5 October 1998 12:19:01 UTC