RE: few questions

["Robinson, Norman B - Washington, DC" <Norman B Robinson usps gov>]

Bill,

	One word: Preferences.

	Accessibility is something that is built into products and
services. Accessibility is quality. How the accessibility is used is by
preference.

	User profiles profile the user. They lead to terms and concerns
that self-identify. They lead to terms that indicate the user is being
tracked. If [insert three letter acronym agency here] created a
distribution with user profiles, you'd likely wonder about the term.

	Just wanted to contribute a few years worth of experience in
political correctness, personal arguments, and community preference for
people who don't wish to self-identify. It isn't about being overly
sensitive, it is about respect and eliminating discussions on semantics
when you simply wish to focus on the technical aspects of a solution.

	Warm Regards,

	Norman B. Robinson


	P.S. I thought some feedback on what I view as generally bad vs.
preferred from the below inline message would be of use:
	accessibility "options" vs. preferences
	a wizard or configuration assistant "helps users select" vs. a
configuration assistant to set preferences
	non-accessible users vs. users that cannot access your content
or information
	"Accessibility" section vs. preferences section
	"users don't self-identify as disabled" vs. "users have
preferences"
	"ghettoize" accessibility vs. having user preference by function
(visual, sound, mobility)
	"user profile" capability vs. "user preference" capabilities

	Don't forget that many times the user may want to change their
preferences to simulate the use by a different user's preference
(testing, remote support) or for a temporary disability (forgot glasses,
etc.). It doesn't matter if those users have any particular or no
disability! 

	Off topic; as it was mentioned I wanted to comment. By avoiding
two separate dialogs which change the same feature, I think they've set
the wrong mandate. Users should be able to change features or
preferences from multiple interfaces, keyboard, system preferences, user
preferences, applications calling the same panels. The mechanism should
be the same, but it is a bad idea to force simplification for human
factors reasons. Usability doesn't always equate to simplicity. I would
recommend you create a user's preference panel that set and stores
multiple preferences. Then you can create multiple default preferences,
useful in testing and evaluation, based on user needs (profiling what a
user needs in advance could be said to enhance the accessibility of your
product) that can be selected as preferences.

-----Original Message-----
From: gnome-accessibility-list-bounces gnome org
[mailto:gnome-accessibility-list-bounces gnome org] On Behalf Of Bill
Haneman
Sent: Tuesday, October 04, 2005 10:09 AM
To: Jason Grieves
Cc: gnome-accessibility-list gnome org
Subject: Re: few questions


Jason Grieves wrote:

> Hi Bill (and all),
>
> I am not quite sure if my last emails went through as I had some major

> email problems.  If these are repeats, pardon me.
>
> 1) Has an accessibility "options" center been discussed in Gnome 
> before?  Similar to what Microsoft has in the control panel, along 
> side with a wizard?  I know older and less technical welcome the 
> wizards and configuration assistants.  It would not seem to hard to 
> do, but I realize it could provide some discrepencies with 
> non-accessible users.  Would there be 2 places to change the same 
> feature?  I.e. keyboard accessibility via Preferences> Keyobard versus

> lets say a tab with the AccessX features

We have resisted, for the most part, the temptation to put all of the 
features that are of interest to accessibility into a special 
"Accessibility" section.  There are many reasons for this, including the

fact that many relevant features are of general interest, the fact that 
some users don't self-identify as disabled, and our desire not to 
"ghettoize" accessibility.   However, some sort of wizard or user-config

helper would be useful, I agree.  I think the best way to do this is via

a general purpose "user profile" capability for the Gnome desktop, but 
this is still a project for the future.  In general Gnome's Human 
Interface Guidelines say one should avoid having two separate dialogs 
which change the same feature.

>
> 2) Bill does the magnifier need to be recompiled to work with the 
> extensions (i.e. Damage) you spoke of?

Yes, it must be built on a system that has the extensions, in order to 
use them.  On most OS'es this should be true, because most distros will 
probably be running a recent XOrg server when building.  However there 
is no guarantee that this is true.  If the magnifier was built without 
DAMAGE or COMPOSITE support, it will report this when started from the 
console in standalone mode, i.e. if you run "magnifier -v -m" the 
magnifier should report if it was compiled without DAMAGE or XFIXES
support.

Bill
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list