Re: FW: UNDELIVERABLE MAIL

hi

i'm not sure what "thread" this message was following, since the
subject seems to have gotten messed up, and I don't have time to
re-search, or expound more fully, right now.

please note, ASCII in some form,  is only the easy half of "this" equation.

if you really want to "operate and control" a keyboard driven device,
in a device independent manner, you need to be able to "press" all the
keys.

mark


At 11:48 AM -0400 5/24/99, Denis Anson wrote:
>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 17:58:55 UTC