Re: Proposed clarification to checkpoint 1.1

I have a suggestion for the reworded 1.1. Here is the current rewording
(also attached):
quote.
     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]
endquote.
The first sentence is, in effect, contradicted by the note. I propose quote
Note: endquote be replaced by quote However, endquote, so that the fact of
an exception is made explicit.

That done, I wish someone could ppresent an accessibility reason for having
this checkpoint, a reason that is not covered by other checkpoints, 1.2 and
1.4 in particular.

Jim Thatcher
IBM Special Needs Systems
www.ibm.com/sns
HPR Documentation page: http://www.austin.ibm.com/sns/hprdoc.html
thatch@us.ibm.com
(512)838-0432


Ian Jacobs <ij@w3.org> on 10/26/99 01:36:39 PM

To:   w3c-wai-ua@w3.org
cc:
Subject:  Proposed clarification to checkpoint 1.1




Hello,

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
through
            the standard keyboard API, the user agent had satisfied
requirements
            for text entry. However, checkpoint 1.1 as written doesn't
capture
            this entirely - it doesn't say that some types of input are
more
            appropriate for a particular API (or inappropriate for
another).

            Question: Are there mouse API-specific input actions that it
doesn't
            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
it.

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

     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
necessarily
be part of it.)

For instance, from the X Window Xlib documentation, section 2.2.3.1:

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

And from section 2.2.3.3:

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

These passages (and there may be better, clearer ones, but I'm not an X
Window
expert) suggest that *the* way to get keyboard input is by listening to
key
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,
more
           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 16:02:04 UTC