Re: Proposed edits to Guideline 1.

Ian,

Suggestion:

To ensure that assistive technologies can both operate the user agent
programmatically (e.g., through simulated keyboard events) and monitor user
agent output (e.g., output text), developers are expected to use each
API appropriately.

Developers should not, for example, pre-rastorize text or convert
text to a series of strokes. These mechanisms may prevent assistive
technologies from capturing
drawn text for alternative renderings.

Rich

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost


Ian Jacobs <ij@w3.org>@w3.org on 04/18/2000 11:06:04 AM

Sent by:  w3c-wai-ua-request@w3.org


To:   w3c-wai-ua@w3.org
cc:
Subject:  Proposed edits to Guideline 1.



Hello,

As part of resolving issues 255 [1] and 260 [2], I would like to
propose the following changes to Guideline 1.

Proposal 1) For the Guideline rationale:

<OLD>
In addition to ensuring device-independent access to all
functionalities,
developers must use the standard APIs of the operating system for
supported
devices. This allows assistive technologies to operate the user agent
programmatically by simulating events from a mouse, keyboard, pen, or
other
input device. For instance, when standard APIs are used, some users who
are
not able to enter text easily through a standard physical keyboard may
still use
voice input or an on-screen keyboard to operate the user agent.
</OLD>

<NEW>
To ensure that assistive technologies can both operate the user agent
programmatically (e.g., through simulated keyboard events) and monitor
user
agent output (e.g., output text), developers are expected to use each
API
appropriately. For example, for rendering text, developers are expected
to use
an API for drawing text. Developers should not, for example, convert
text to a
bitmap to be rendered via a graphical API; this may prevent other
software from
being able to use the text.
</NEW>

Proposal 2) Checkpoint 1.1


<OLD>
1.1 Ensure that every functionality available through the user
    interface is also available through every input device API supported
    by the user agent. Excluded from this requirement are
functionalities
    that are part of the input device API itself (e.g., text input for
the
    keyboard API, pointer motion for the pointer API, etc.) [Priority 1]

           Note. The device-independence required by this checkpoint
                 applies to functionalities described by the other
checkpoints
                 in this document (e.g., installation, documentation,
user agent
                 user interface configuration, etc.). This checkpoint
does not
                 require user agents to use all operating system input
device
                 APIs, only to make the software accessible through
those
                 they do use.
</OLD>

<NEW>
1.1 Ensure that every functionality available through the user interface
    is available through every input API implemented by the user agent.
    [Priority 1]

          Note. This checkpoint does not require developers to
                implement all operating system input APIs, only to make
the
                software accessible through those they do implement. The
                device-independence required by this checkpoint applies
to
                the functionalities described by the other checkpoints
in this
                document (e.g., installation, documentation, user agent
user
                interface configuration, etc.). This checkpoint does not
require
                developers to reimplement the input methods associated
with
                the keyboard, pointing device, voice, and other device
APIs.
                For example, developers are not required to implement
text
                input through a mouse API.
</NEW>

Proposal 3) Checkpoint 1.2

Add the following note after the existing text:

<NEW>
 Note. Developers should use APIs available at a higher level of
       abstraction than device APIs, provided that, in turn, these
       higher level APIs make use of the standard device APIs for
       the operating system.
</NEW>

Proposal 4) Checkpoint 1.4

<OLD>
1.4 Ensure that every functionality available through the user
    interface is also available through the standard keyboard API.
    [Priority 1]
        Note. This checkpoint is an important special case of
              checkpoint 1.1. The comment about low-level
functionalities
              in checkpoint 1.1 applies to this checkpoint as well.
Refer
              also to checkpoint 10.8.
</OLD>

<NEW>
1.4 Implement the standard keyboard API of the operating system and
    ensure that every functionality available through the user interface
is
    available through this API. [Priority 1]
        Note. This checkpoint always applies on systems with a
              standard keyboard API. This checkpoint is an important
              special case of checkpoint 1.1. Refer also to checkpoint
10.8.
</NEW>


 - Ian

[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#255
[2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#260
--
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 18 April 2000 13:00:06 UTC