- From: Charles McCathieNevile <charlesn@srl.rmit.EDU.AU>
- Date: Thu, 29 Oct 1998 02:27:45 +1100 (EST)
- To: WAI GL <w3c-wai-gl@w3.org>
- cc: WAI UA group <w3c-wai-ua@w3.org>
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