Re: Guidelines

>>> <w3c-wai-gl@w3.org> (Charles McCathieNevile) 10/22 4:35 AM >>>
...
2. The use of 'event' attributes (onMouseOver, onFocus, etc) can cause 
problems, because only some of these events have keyboard (let alone 
voice-input) equivalents. I think this is one that needs to be talked 
through with UA, PF and DOM (the groups that spring immediately to mind) 
but a sensible first pass would be to suggest that only those events 
which can be described as logical rather than device-dependent (onSubmit and 
onChange are the two which spring to mind, although with a little help 
from our friends it should be possible to expand the repertoire, and UA 
are dealing with this problem at the moment) should be used.
...
<<<
I agree that the distinction should be made between syntactic, application-level (logical) events and device-dependent, action-level events. That is, identify "what I'm doing" or "what is happening" instead of "how I'm doing it"? This parallels the use of HTML to identify the purpose of an element <em> rather than its rendering in some medium <b>. Similarly, the Guidelines should encourage the use of application-level events while discouraging the use of action-level events.
    With this emphasis, onFocus and onBlur *are* application-level (logical) events. I can focus on a field by tabbing to it, by clicking in it, or possibly by referring to its label. The means by which a user can focus on a field is (should be) a browser issue, not an authoring issue. "Focus" and "Blur" are independent of the means used to produce these effects.

There may also be a need to distinguish between events which are the direct result of user action - for example: onSubmit, onReset, onFocus, onBlur - and those that occur asynchronously or represent an unexpected result - such as onLoad, onError. For example, I'd like to be able to identify an error message to be presented to a user in case a required field is incomplete, or a field contains incorrect data. This error might be presented to the user as soon as they try to leave a field (onBlur) or when they try to return the form to the server for processing (onSubmit). Ideally, the validation criteria and error messages should be directly associated with the field, much as a <LABEL> can be. Presently, there is no syntactic, application-level means of identifying this information. As an author, I must decide if, when and how to present the error to the user, which immediately raises accessibility concerns.

<author>Chris Kreussling</author> 
<disclaimer>The views expressed are those of the author and do not necessarily reflect the position of the Federal Reserve Bank of New York or the Federal Reserve System.</disclaimer>

Received on Thursday, 22 October 1998 12:07:50 UTC