RE: Events

I would agree that supporting device independent input would include
supporting keyboard input for control.  However, I think that the techniques
document would have to specifically address keyboard and ASCII code for
control of all functionality.

Denis Anson, MS, OTR
Assistant Professor
College Misericordia
301 Lake St.
Dallas, PA 18612

Member since 1989:
RESNA: An International Association of Assistive Techology Professionals

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
Of James Allan
Sent: Friday, May 21, 1999 1:31 PM
To: WAU-ua
Subject: RE: Events

Thought I would bring these messages below to the list. I reviewed the
guideline and don't find a place where this is directly addressed. It can
fall into

Guideline 4.2 Support input and output device-independence or
Guideline 4.3 Support accessible keyboard input

I would propose a checkpoint in 4.3 (because it mentions keyboard, but could
also fit in 4.2)

4.x.x  Ensure keyboard access to all elements otherwise operable by a mouse
(including pulldown)

there is some overlap with the Navigation in guidelines

Guideline 6.2 Provide information about document structure
Guideline 6.3 Provide information about events

my concern is that the user can navigate to an element that has an event,
activate the event (menu pulls down) and can navigate the results of the
event (move down the list) and activate an appropriate link or other control
from the keyboard.


Jim

-----Original Message-----
From: Daniel.Dardailler@sophia.inria.fr
[mailto:Daniel.Dardailler@sophia.inria.fr]On Behalf Of Daniel Dardailler
Sent: Friday, May 21, 1999 4:37 AM
To: allan_jm@tsb1.tsbvi.edu
Subject: Re: Events



> Will the onfocus work with a keyboard directed focus change (tab key). For
> example, web page with pull down menus. Currently moving focus with the
> keyboard does not cause the menu to pull down. There is also a need for
> keyboard navigation of menus and activation of selection once they are
> pulled down.

I don't know if it will, but that's what we should be asking for in UA
guidelines: keyboard access to all elements otherwise operatable my a
mouse (including pulldown)

-----Original Message-----
From: Jim Allan
To: Daniel.Dardailler@sophia.inria.fr

Daniel,
Will the onfocus work with a keyboard directed focus change (tab key). For
example, web page with pull down menus. Currently moving focus with the
keyboard does not cause the menu to pull down. There is also a need for
keyboard navigation of menus and activation of selection once they are
pulled down.

Jim Allan, Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9453  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

-----Original Message-----
From: w3c-wai-pf-request@w3.org [mailto:w3c-wai-pf-request@w3.org]On
Behalf Of Daniel Dardailler
Sent: Thursday, May 20, 1999 10:45 AM
To: w3c-wai-pf@w3.org
Subject: Events

Our next telecon is next Friday (May 28) and Events is on the menu.

Here is my current take on that, based on discussion on the list with
Charles and others.

==========

HTML4.0 specifies several events that can be used to trigger scripts.

Some are logical:

  onload, onunload, onfocus, onblur, onsubmit, onreset, onselect, onchange

Some are input device specific

  onclick, ondblclick, onmousedown, onmouseup, onmouseover,
  onmousemove, onmouseout, onkeypress, onkeydown, onkeyup

Our proposal for future versions of HTML (e.g. XHTML) is to mark this
second set deprecated and to replace it with the following
equivalents:

  onactivate (for onclick, onkeypress)
  onsuperactivate (for ondblclick, onkeypress+mod)
  onarm (for onmousedown, onkeydown)
  ondisam (for onmouseup, onkeyup)
  onfocus (for onmouseover)
  onblur (for onmouseout)

  onmousemove (since there's no clear device independent equivalent of
       onmousemove, so we could keep it in with a warning mentioning this,
       and suggesting that only decorative effects be triggered this way)


The real work behind this change needs to happen in User Agents land.
In particular, there is an interim period where UA needs to treat
equivalent events the same way, e.g. if a page has an onclick init,
the UA should allow a trigger using onkeypress, if onmouseout is used,
keyboard traversal and onblur should trigger the script too, etc.

A related feature I've been thinking about is a new attribute on the
SCRIPT element to indicate if the script is purely decorative/visual
or not.
This would allow UA to ignore most of the script at the end of
onfocus (e.g. onmouseover), onarm, etc.

Received on Friday, 21 May 1999 15:51:03 UTC