RE: character Input -- Checkpoint 2.1 (revisions from Jan 8 Telecon)

1) Good summary Jason.

2) We need to be careful with our "or"s and 'ands"
If we say keyboard or speech.  Then a speech only device qualifies.
If we say Keyboard and speech. Then we are requiring both -- but forgetting
many others.

3) I don't think we should coin a new term. It will only lead to confusion.
And "jargon" violates our rules unless it is not possible to avoid.

4) The shortest I can come up with then is

'All functionality achievable through character input" 
   --  Where "Character input" is defined as "Unicode characters and
standard cursor movement and data entry controls,   (i.e. tab, shift tab,
enter, 4 arrowkeys, escape, backspace, & delete).

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: Jason White [mailto:jasonw@ariel.ucs.unimelb.edu.au] 
Sent: Friday, February 07, 2003 6:14 PM
To: Marco Trevisan | Bazzmann.Com
Cc: ishida@w3.org; gv@trace.wisc.edu; w3c-wai-gl@w3.org
Subject: Re: character Input -- Checkpoint 2.1 (revisions from Jan 8
Telecon)

This is an interesting discussion. My concern, however, is that it is
moving in circles. What I mean is that we are covering old ground that
has been well trodden several times in teleconferences, reviving the
same arguments and counter-proposals that have been considered in the
past without making any progress.

We agreed twice (in two different teleconferences) that "character
input" is really what we mean, as it covers everything from keyboards
to speech systems to single switch input devices to on-screen
keyboards to interfaces that allow one to select words/characters from
a displayed list, etc. What the application receives in each case is
some form of character input, whether in Unicode or an
application/platform-specific encoding.

I personally think "character input" is sufficient. Nevertheless one
could say "character input and commands that move the focus among user
interface controls", or some variation on the above wording. I think
this is ultimately what we want to say. To make the sentence shorter
we could coin another technical term such as "discrete focus event",
defined as an event that assigns focus to a specific component of the
user interface. If this is too broad we could be more restrictive by
defining the minimal actions (move back, move forward, activate...)
with which it should be possible to operate the user interface in
addition to the provision of actual characters.

The point is to define "focus event" for this purpose so that events
specific to a pointing device which include coordinate values, don't
qualify. This should then cover exactly what we want.

Received on Monday, 10 February 2003 02:08:36 UTC