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

RE: Chuck Hitchcock comments on last call UAGL [Fwd: User Agent Guidelines 1.0 Comments]

From: Denis Anson <danson@miseri.edu>
Date: Wed, 1 Dec 1999 15:01:01 -0500
To: "Ian Jacobs" <ij@w3.org>, <w3c-wai-ua@w3.org>, <jbrewer@w3.org>
Message-ID: <OCEDIDJABCKNMLGMBFLGAEDDCFAA.danson@miseri.edu>



-----Original Message-----
 >
> In the Introduction in the section related to user interface, it might be
> helpful to include a comment about providing a "reset defaults" function
for
> user settings.  This can be global or by groups of settings but I find
that
> many individuals fuss with settings to a point where they forget the
> original recommended defaults and really need to start over.

This sounds like a Technique, but the WG should consider whether
this should be a checkpoint, say in the section on configuration.
I think it might be a checkpoint, with a priority 2 level. Restore defaults
is a common feature on highly configurable products, since you can easily
make the product unusable if you forget the changes you've made.  Changing
back to a known standard is a good way to recover.


> In Checkpoint 1.1., Principles of Accessible Design:  I am not aware of
any
> real evidence indicating that contextual access through cascading menus is
> supportive of those with cognitive impairments although common sense would
> seem to indicate that this might be true.  On the other hand, menus that
are
> not stable or predictible might also be problematic for some.  The
> organization and grouping of menu items is much more important.  I would
> change the language in Contextual access to read:
>
> -->Contextual access (e.g. through cascading menus, through help systems,
> etc) may help users with cognitive impairments and others unfamiliar with
> the tool.

Unless there are objections, I will use your language.
If we are talking about menus with sub-menus, they do help those with
cognitive deficits who can't process too many options at once, but they are
a real problem for those with motor control problems, since it's very easy
to fall off the side of the menu, and have it collapse.  Even with normal
hand function, I have this happen often enough to be annoying.


> Checkpoint 1.4: Wonder about the use of the word "every". The explanation
of
> the checkpoint mentions that it should be efficient enough to support
> production use - which I think is appropriate, it can't be possible to do
> everything through the keyboard or we wouldn't need other forms of input.
> But the "every" in the first sentence contradicts that.

I would argue that if you can't do something at all with a given device,
the UA is broken. I can enter text with the mouse if I have an onscreen
keyboard. However, I don't want to do so since I can use the keyboard
(and for that particular functionality, I don't want to require the
UA to support text entry with the mouse; it's still conceivable,
however).

Thus, in my opinion, users who can use different devices should be
able to use the one best-suited to their abilities and the task at
hand. Users who can only use one device should be able to operate the
tool with that device alone.

I agree with Ian here.  Using an on-screen keyboard is ridiculous for a
person who can use the physical keyboard, because the physical device is
faster and more effective.  But if you are using a mouse emulator, and can't
use the keyboard, then being able to use an on-screen keyboard makes the UA
usable.  Similarly, if you can use a keyboard, but not a mouse, then having
keyboard equivalents for all functionality makes the UA accessible, but a
person who can use the mouse will probably prefer to use that as the input
device.
Denis Anson, MS, OTR
Assistant Professor
College Misericordia
301 Lake St.
Dallas, PA 18612

Member since 1989:
RESNA: An International Association of Assistive Techology Professionals
Website: http://www.resna.org
RESNA ANNUAL CONFERENCE -- "RESNA 2000"
ORLANDO, FL, JUNE 28 -- July 2, 2000
Received on Wednesday, 1 December 1999 14:59:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC