FW: UNDELIVERABLE MAIL

When I think of "device independent input" I generally consider that to be
accessible via ASCII codes.  ASCII is the lingua franca of electronic
communications (possibly with extended ASCII for international
applications), and is also generated by most alternative input systems
(except mouse emulators).  Even speech input technologies generate ASCII
codes.

Hence, if a program is completely controllable via ASCII codes, it can be
controlled by any device that can generate ASCII codes.  That provides
"device independent" input, and, of course, includes keyboard control.
(However, it could cause problems with "Alt" codes, since they don't have
ASCII equivalents that I know of, unless they are in 8 bit ASCII.)

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 Charles McCathieNevile
Sent: Friday, May 21, 1999 3:58 PM
To: Denis Anson
Cc: allan_jm@tsb1.tsbvi.edu; WAU-ua
Subject: RE: Events

Actually, for a voice-input system there are some extra constraints which
can
arise. It seems to me that device independence is the P1 requirement, and
keyboard access is a good way of doing it most of the time. Specific
keyboard
access may be a P2 requirement in its own right - I am not sure. Remember
that a 108-key keyboard is not universal either.

Charles McCN

On Fri, 21 May 1999, Denis Anson wrote:

  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.






--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Monday, 24 May 1999 11:48:35 UTC