Re: Proposed modification to Guideline 1 and Guideline 2

Al Gilman wrote:
> 
> Ref: http://www.w3.org/WAI/UA/1999/10/g1g2-proposal
> Note: I haven't cut this down, skip to AG:: for my comments.  Sorry I am
> not up to date with discussion since this was posted.  You may have got all
> these points already.

We had a big discussion at this week's teleconf, but let's see
how we scored!
 
>              Proposed modification to Guideline 1 and Guideline 2
> 
> Background
> 
>    The following proposal attempts to address a number of concerns about
>    Guidelines 1 and 2 that were raised by Marja Koivunen (refer to
>    [1]Marja's message of 29 September 1999. See also [2]Marja's comments
>    on Guidelines 1 and 2 upon which this proposal is founded. It also
>    takes into account [3]changes proposed by Rich Schwerdtfeger.
> 
>    The goals of this proposal are the following:
>      * Ensure that it is clear how important the keyboard is to
>        accessibility. At the same time, make sure that developers realize
>        that the keyboard is not the only solution to accessibility:
>        certain functionalities should be addressed in a larger context
>        than keyboard alone.
>      * Clarify that in terms of the user interface, the user needs to
>        know what the current behavior is (e.g., keyboard bindings), not
>        whether the behavior initiated with the user agent or author.
> 
> AG:: I believe that that is incorrect in human-computer interaction terms
> a.k.a.
> human factors.  The first or highest requirement is indeed that the user be
> able to know and look up what the exact key bindings are right now; but it
> is also valuable and important that the user be able to know and remember
> which of these are there because of the client program and will be the same
> for all pages.   Conversely which are ephemeral and cannot be expected to
> act the same elsewhere.

So two criteria:
1) Current config?
2) Which are user agent-supplied? Author-supplied?

The stumbling block of the teleconf was whether the current
config information should gloss over (or not) the origin
of the setting. There will be a proposal for two checkpoints
(one, higher priority, for current config from the UA
and a second, lower priority, for current config from the author).

We did not consider your requirement for knowing what 
part of the config will persist across pages .
 

>   Guideline 1. Support input and output device-independence
> 
>    1.1 Ensure that all functionalities offered through the user interface
>           are available through input device APIs implemented by the user
>           agent. Functionalities include installation procedures, control
>           of the user interface, access to documentation, and
>           configuration. [Priority 1]
>           Note. Functionalities include being able to show, hide, resize
>           and move graphical [5]viewports created by the user agent.
>           Note. The device-independence required by this checkpoint
>           applies to functionalities described by the other checkpoints
>           in this document unless otherwise stated by individual
>           checkpoints.
> 
> AG:: I don't think you have this stated just right just yet.
> 
> Supported devices: should be the standard devices for the environment plus
> others ad lib.

What part is missing? 

 - "Standard API" is covered by another checkpoint"
 - "Other devices" is not prohibited by 1.1 as stated?

There are two pieces to the 1.1 above:

 - All functionalities
 - All implemented APIs.

I have promoted leaving the third axis, "Standard", for another
checkpoint
to help simplify (although no one is convinced that it's simpler...)
 
> Device communication:  Where there is a standard API for these devices
> supported by the environment, this API should be used.  In general, if the
> OS or language supports a standard mechanism for intercepting the
> communication with a device, the communication with that device should pass
> through this mechanism so that the device may be emulated by AT through
> this mechanism at the user and AT's discretion.

That isn't covered by 1.3 below?
 
>    1.2 Ensure that the user can interact with all [6]active elements in a
>           [7]device independent manner. [Priority 1]
>           For example, ensure that the user can [8]activate links of a
>           client-side image map in a device-independent manner (e.g., by
>           making them available as text links).
> 
>    1.3 Support [9]standard input and output device APIs for the operating
>           system. [Priority 1]
>           Note. What is "standard" for a particular environment will
>           change over time. Today, for example, the mouse and keyboard
>           are standard in a graphical desktop computer environment.
>           Tomorrow, voice input and output may be standard. For a small
>           device, standard input may come from a pen or keypad, and
>           output through an LCD screen.
> 
>    1.4 Ensure that all functionalities offered through the user interface
>           are available through the standard keyboard API.
> 
> AG:: To me, display is a functionality.  I would state this more carefully
> as "ensure that all user actions or commands may be exercised through..."

I think we touched on this from another angle by discussing
text input and mouse motion: those functionalities aren't required
to be reimplemented by different APIs. I would put display in that
as well (closely bound to a particular API).

We were looking for a way to limit the scope of "functionality".
I would support your "user action or command" modifier.
 

>   Guideline 11. Allow the user to configure the user agent
> 
>    11.1 Document the default [10]input configuration for the keyboard,
>           graphical user interface, voice commands, etc. [Priority 1]
> 
> AG::  Document ... in universally-accessible media [WEBCONTENT].

Covered by another checkpoint in documentation guideline.

>    11.2 Provide information to the user about the current [11]input
>           configuration for the keyboard, graphical user interface, voice
>           commands, etc. [Priority 1]
>           The current configuration is the result of a cascade of
>           author-specified user interface information (e.g., "accesskey"
>           or "tabindex" in HTML), browser defaults, and user-modified
>           settings.
> 
> AG:: I would say "provide interactive access to..." rather than just "provide
> information" only because on first reading the latter could be taken for
> paper documents (even 'though it becomes obvious later in the sentence that
> this won't work..)

It could be read only if the current config is always the default
config, but I see your point. I'm ok with that change.

Thanks Al! Other modifications from this week's
teleconf will appear in that next draft.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Thursday, 28 October 1999 23:18:52 UTC