Re: that darned accessibility capplet

[Bill Haneman <bill haneman sun com>]

Earl Johnson said:
> 
> Hi,
> 
> I'm not on this alias so please make sure your replies include my email
> - earl johnson sun com
> 
> This is re-run feedback from me but I think the capplet should be a
> tabbed pane with 2 tabs - one tab for StickyKeys, MouseKeys, and
> ToggleKeys; the other a keyboard response tab containing RepeatKeys,
> BounceKeys, and SlowKeys. This sure would go a long way in reducing the
> capplet's current clutter and make the interface easier to use (e.g.
> the individual range setting controls wouldn't have to be so small).

If you like it Earl, I certainly won't contradict you :-).

The size issue is important for mouse users, but I always thought most
accessX users were keyboarders?  Not that we want to ignore the
keyboard-plus-mouse folks.  What do you think about the fact that this
would require another keystroke (to change "notebook tabs") sometimes?
(e.g. does size really matter?)
 
... more comments below....

> > >  - the title says "AccessX" which is UNIX-workstation-cruft
> > >    terminology.
> > 
> > It does looks a little ugly, but 'accessx' is a long-standing and
> > well-understood term in the accessibility community.  Having it only
> > show up in the window title was a compromise; nobody looks in window
> > titles anyway :)  Perhaps this could go away after a few releases when
> > people have made the connection, but I guess we'll always be getting new
> > users from other desktops, hopefully!
> 
> EJ	AccessX is long standing in the X and Linux realm but the real
> 	portion that is inherited cruft is Access*. The other names
> 	this group of features are known as is AccessPak (Msoft's
> 	name), AccessDOS (for DOS), and I forget what Apple calls it
> 	(tho I don't remember it having the crufty Access name in it).
> 	As further background, the X and DOS were chosen to signify the
> 	platform they ran on. Following this thought, if a new name is
> 	desired maybe it could be called AccessG where the G signifies
> 	GNOME. Or, just playing, AccessGeeWhiz.
> 
> 	But staying with AccessX as Calum suggests shouldn't cause
> 	problems because most users on the Unix, Linux, and Windows
> 	platforms know what AccessX is or recognize that Access* means
> 	this is where they find the features AccessX and others provide.
> 
> >
>  
> > >  - the "enable keyboard accessibility" checkbox is bad; most users
> > >    here will interpret it to mean "make my keyboard work" and wonder
> > >    why they would uncheck it.
> > > 
> > >    Also, there is no reason why you can't just check or uncheck the
> > >    four specific checkboxes (mouse keys, bounce keys, etc.) as you
> > >    have to do on Windows XP, especially given the need to trim the
> > >    size of this control panel. You don't need the save-myself-a-couple
> > >    clicks extra checkbox that has an unclear label.
> > 
> > This is a possibility I guess.  One problem you would get with doing it
> > this way is when the "turn off when unused for n seconds" feature kicked
> > in, there would be no quick way of turning it back on again.
> > 
> > Unfortunately the rationale for some of these features has been lost in
> > the mists of time-- they've been in AccessX for years. (Perhaps Earl can
> > remind us of some of them-- cc'ing him). We would definitely need to run
> > that sort of feature change past the accessibility community before we
> > could go ahead with it.
> > 
> EJ  On "enable keyboard accessibility"
> 	AccessX features are supposed to be invokable from any system.
> 	This is great in public and collaborative environments for
> 	people who need its features - no matter where they go they can
> 	make the right keypresses and turn on AccessX features without
> 	having to open up the AccessX interface (which would be
> 	impossible for someone who can't use a mouse). But this power
> 	sucks for those who don't need the features and use
> 	applications that cause this user to inadvertantly invoke a
> 	feature (e.g. shoot-em-up games regularly use left and right
> 	shift keys to control guns, etc.). So "enable keyboard
> 	accessibility" was added to let the user who didn't need
> 	AccessX features prevent the system from turning on a feature
> 	inadvertantly from the keyboard (e.g. it prevents 5 taps on the
> 	Shift key from invoking StickyKeys).
> 
> 	Window's added an additional feature along these lines that
> 	AccessX never had - it posts a popup the first time any feature
> 	is invoked from the keyboard and asks the user then if they
> 	want to fully disable keyboard accessibility. This would be a
> 	good thing to see added to the GNOME desktop.

Yeah, that does sound cool, and it will help prevent weird but reports
;-)

>     On "turn off when unused for n seconds"
> 	Public environments such as libraries need to provide systems
> 	that all users can access. But they typically can't afford to
> 	purchase machines that only people with disabilities can use -
> 	they want/need each system they purchase to be usable by all
> 	users. So while AccessX helps places like libraries minimize
> 	the number of systems they need to purchase, problems will
> 	abound for people without disabilities who use a system after a
> 	person who has turned on an AccessX feature leaves without
> 	turning the feature off. The auto turn off feature turns off
> 	all AccessX feature after a specified period of keyboard
> 	inactivity and was introduced to prevent this problem.
> 
> Earl