Re: Proposal to modify checkpoint about easy default access (10.8)

[Discussion, not recommendation...]

At 07:27 PM 2000-07-28 -0400, Ian Jacobs wrote:
>Hello,
>
>Checkpoint 10.8 of the 7 July UA Guidelines [1] reads:
>
>    10.8 Ensure that the default input configuration allows 
>         easy activation of frequently used functionalities. 
>         [Priority 3] 
>

AG::

As stated, this is a general request for usability quality in the shipping
default user interface.  I agree that this matters for people with
disabilities, but this wording states the generic "universal design"
criterion and does not in any way yet isolate a requirement peculiar to
people with disabilities.  Note that I do not hold that the document cannot
apply such as requirements, only that this one as stated is purely generic
at present.

This is an area where a binary description of the requirement is about as
bad a fit to reality as for any criterion in this domain.  The real
requirement is quantitative and covers all functionalities.  This is to
minimize the frequency-weighted activation effort across all
functionalities.  You can blow the bottom line usability with a very
frequently used functionality which is just a little too difficult or with
a relatively infrequent [but functionally essential] function (such as
configuration) which is highly unusable.

A related criterion that this statement may reflect is to minimize the
configuration effort required to reach adaptive profiles or bindings.

This point is the User Agent parallel to the web content principle "it is
especially important that your home page be accessible, where the largest
number of people are going to enter your site."  The User Agent principle
is that "it is especially important that the shipping default configuration
of the user interface be broadly usable, because that is where _everyone_
starts whether they take advantage of configuration capabilities (the
minority) or not (the majority)."


>In considering the minimal requirements for this checkpoint
>we can break it down into two parts:
>
>1) The set of "frequently used functionalities".
>2) The definition of "easy activation".
>
>This checkpoint does not make any requirements about
>the size of the default input configuration (i.e., how
>many bindings must be offered).

AG:: 

It does not require a unique binding.  It applies to a unique binding,
however.  This is clear in the terms used to refer to the binding that this
checkpoint governs.

Use of the article 'the' indicates that a unique binding is under
discussion.  The current language must be interpreted as referring to the
shipping default, which is a single profile or binding.  And it is
appropriate to address this checkpoint to that unique binding.
If you wish to indicate a library of preconfigured profiles, please say
"binding options preconfigured and made available as part of the product"
and not "the default" because "the shipping default" is unique and is all
most people ever use.  The latter is what this checkpoint should be about.

Yes, it is impossible to make one configuration that makes things 'easy'
for everyone.

IJ::

>
>In light of resolutions from yesterday's teleconference [2]
>related to checkpoints 10.4 and 10.5, I'd like to propose

>that checkpoint 10.8 be modified as follows:
>
>  <NEW>
>    10.8 Ensure that the default input configuration includes
>         bindings for the following functionalities (subject
>         to applicability considerations): [insert modified
>         list of 20 [3] here] [PRIORITY 2]
>  </NEW>
>
>Notes:
>
>1) Since the checkpoint only talks about the list of functionalities,
>   and the list of 20 is also the minimal list for two other 
>   priority 2 checkpoints (10.4 and 10.5), I propose that we 
>   elevate 10.8 to a Priority 2 checkpoint. This modification allows us
>   to cross reference 10.8 from 10.4 and 10.5 for the list of 20 
>   functionalities.
>
>2) I have removed the part about "easy access" in the reformulation. 
>   This is because checkpoints 10.4 and 10.5 (as resolved yesterday) 
>   impose a limit on binding complexity in the case of the keyboard 
>   (modifiers plus single key or single key alone). Checkpoint 10.4
>   does not impose a binding complexity limit for other types of
>   input, however.
>
>3) This proposal supersedes a previous proposal I sent about 10.8 [4].
>
>In short:
>
>1) We gain for the keyboard, requiring easy access at a P2 level
>   (by combining 10.4, 10.5, and 10.8).
>
>2) We lose a P3 requirement for easy access for other input 
>   modes (e.g., voice, graphical user interface).

AG::

On the one hand, the community which has easy access to selecting and
activating any key on the keyboard (or any prime-key plus N modifier keys)
is a special interest group, just as the blind and visually impaired
community is a special interest group as regards the domain of the web
content guidelines.

On the other hand, the keyboard plays a central role in access to commands
[in the desktop environment] comparable to the central role of text in the
content accessibility guidelines.

I believe that to understand why there should be a special rule for
keyboard at this point requires us to indulge in the politically incorrect
"numbers game."  The point is to realize that "the default user interface"
is a unique binding per shipping product.  The realities are that despite
the best efforts of accessibility groups to build options into the product
that offer enhanced usability for people with disabilities, the install
proceedures always offer the user a default and the great preponderance of
users (probably including users with disabilities) just accept the
defaults.  There is a strong central tendency among the installed initial
user interface bindings around the shipping default.  So it makes sense to
address this unique binding by a special rule.

Likewise, the keyboard access mode for commands is the single mode that has
the best performance in terms of making command input accessible across
different classes of people with disabilities.  It doesn't by itself
deliver adequate breadth, but no other single mode or binding offers the
same breadth.

What this checkpoint is addressing is the "zero configuration" binding of
the user interface, and it makes sense to say that it, in particular,
should look good as viewed through the most-likely-to-be-successful access
mode, in particular.


There is still the more general principle that the configuration effort to
reach a binding that works for you should be minimized.  But the shipping
default is unique, and the keyboard is unique as the leading
cross-disability-accessible command input modality in the desktop
environment.  There is no proble inserting a checkpoint which says "in
particular..." and links these two.  In fact, it doesn't make sense to try
to cover the "configuration effort to reach a binding that works for you"
with one minimum implementation.  That is a higher-level requirement and
will need to be answered in different ways for different people.

Al

>
>Another option is to make this change and include a P3 checkpoint
>(essentially the old 10.8) for input modes other than the keyboard. 
>However, I don't think that this is necessary because just requiring
>the "list of 20 functionalities" in the default UA input configuration
>is probably a pretty good guarantee that they will be readily available
>(i.e., not buried).
>
> - Ian
> 
>[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707
>[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0179.html
>[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0037.html
>[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0134.html
>-- 
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>

Received on Saturday, 29 July 2000 13:23:40 UTC