Re: Guidelines - events (not Xposted)

Nir wrote that we shouldn't 'complain' about events like rollovers. I
think that while he is right in the sense that they do not yet compromise
accessibility, there will hopefully come a time in the near future when
there is a better mechanism for events. In the example of a rollover it
could happen by using a 'logical event' to operate on the Style properties
of an element. This would make that rollover transferable across
different media (potentially at least). 

However, if we leave the possibility unremarked, when we come to the
situation where wwe are in a position to fix it up properly we will have
not only rollover events working as they do now but event driven dynamic
objects for which there is no simple accessible alternative, written using
an out of date 'mode'. This is the problem we currently have with TABLEs
and CSS - the TABLE has become such a ubiquitous (although very clearly
wrong) way of doing things that it is difficult to undo it, and the real
solution looks to be a slow transition as sites are completely rebuilt,
rather than a logical translation to a better mode. This contrast with the
use of a standardised D-link of some kind, which can relatively easily be
converted to LONGDESC when the time comes. 

If we could identify events we wanted, pathways by which some existing 
events could be translated into new ones (as happened with MENU and DIR, 
which were transformed into lists, as I understand it) and include those 
in the guidelines then we will not convince everyone. But at least the 
information will be there for those who are interested. 

Perhaps what we want are some informative notes looking towards future 
developments, and the way in which changes are likely to be made - such 
as:

Avoid the use of device specific events such as onMouseMove in favour of 
logical events such as onBlur. Note that some device-specific events are 
likely to be autmatically translated into logical events (onClick and 
onKeyPress to an onActivate event) while others may simply disappear as 
being too specific to a particular device to be universally generalised 
(onDblClick)

These sort of guidelines would require thought and input from UA, and 
probably a number of other groups as well.

It may be a couple of years before these features might be implemented in
browsers which are commonly used, (based on the theory that take-up rates
on new browsers are slowing down). On the other hand it would provide a
good incentive for people to read the guidelines carefully if they gave
ideas about how to future-proof (by supporting the accessibility features
which we hope will become part of the next generation of the web) their
material a little better. Again, it seems that people are finding it
harder to justify the expense of rapid changes to their websites in the
real world, and as it moves from an interesting new gadget to a serious
part of working the cost of playing with it has to start being justified
better. 

(This is really a rehash of the argument for supporting CSS from the 
beginning rather than saying 'use TABLE' now, but change it when CSS 
layout is introduced. Or another way of looking at the consequences of 
that argument.)

worth 2 cents ?

Charles McCathieNevile

Received on Wednesday, 28 October 1998 10:32:06 UTC