W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Proposed clarification to checkpoint 1.1

From: Ian Jacobs <ij@w3.org>
Date: Tue, 26 Oct 1999 14:36:39 -0400
Message-ID: <3815F4B7.BEC67054@w3.org>
To: w3c-wai-ua@w3.org

Jim and I had a brief discussion in which were raised a couple of
issues about checkpoint 1.1 (from [1]):

         1.1 Ensure that all functionalities offered through the user 
             interface are available through input device APIs
             implemented by the user agent. [Priority 1] 

1) Issue 1: The general goal of this checkpoint is that 
            the user be able to operate the user agent through
            supported input devices. 

            Proposed Clarification: Jim suggested that we
            say that the user must be able to "initiate" all user
            agent functionalities.

2) Issue 2: Some functionalities may actually be bound to one (or more)
            API. For example, text entry is more naturally done (if not
            exclusively) through the keyboard API. The user agent should
            not be required to allow text entry through the mouse API if
            the mouse API doesn't support text entry. 

            Recall that Harvey asked whether the user had to be able to
            enter text with the mouse. The answer was "no" - this is the
            realm of the keyboard and that by supporting text entry
            the standard keyboard API, the user agent had satisfied
            for text entry. However, checkpoint 1.1 as written doesn't
            this entirely - it doesn't say that some types of input are
            appropriate for a particular API (or inappropriate for
            Question: Are there mouse API-specific input actions that it
            make sense to simulate with the keyboard API?

            Statement of principles:
             1) It is bad design to bind a high-level functionality
(e.g., Open View)
                to an input method that is tightly bound to a single
input device API.

             2) It is good design to use the appropriate input device
API for
                actions (such as text entry) that are closely bound to

In light of these two issues, I propose the following clarification to

     Ensure that every functionality offered through the user 
     interface is available through every input device API 
     implemented by the user agent. Note: User agents are not
     required to reimplement low-level functionalities (e.g., 
     for character input or pointer motion) that are inherently bound
     to a particular API and most naturally implemented through
     that API. [Priority 1] 

(The Note might go after the checkpoint text as well, and not
be part of it.)

For instance, from the X Window Xlib documentation, section

Key events from extension devices contain all the information that
is contained in a key event from the X keyboard. 

And from section

Motion events from extension devices contain all the information
that is contained in a motion event from the X pointer.

These passages (and there may be better, clearer ones, but I'm not an X
expert) suggest that *the* way to get keyboard input is by listening to
events (DeviceKeyPress and DeviceKeyRelease) and that motion events
provide information about pointer movements. It's therefore only natural
to use the appropriate parts of the X Window protocol to handle
character input and 
user agents should not be required to implement character input through
another API (or another part of the X event model in this case).

This is probably obvious to developers anyway. 

3) Issue 3: It's not clear enough that some checkpoints are redundant,
           specific instances of other checkpoints. We should state this
           clearly so that readers don't think the checkpoints are 
           orthogonal in scope.
w[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19991022/
[2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#68
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Tuesday, 26 October 1999 14:36:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC