Hi Calum, gang,
[cc-ing the gnome-accessibility-devel list & sending replies there
for future discussion]
Thinking about this problem - otherwise undistinguished static text
updating in the login/password dialog - and a related general problem
of "wizards" - where some/much/most of an existing dialog/window
changes throughout the user interaction, I wonder if your offhand
suggestion below actually makes some sense. Maybe we should look at
adding some sort of additional state - since we don't have the ability
to convey multiple roles in our API - to those objects that should be
flagged for AT as being "self-updating" or some such.
While in the end there may be no complete substitute for custom scripts
in places like these wizards for the best user experience, I wonder if
we can general automatic reasonable behavior in these places by exactly
the kind of tagging you suggest below it would be nice to not invent.
An algorithm we might use is for things like screen readers to always
auto-announce changes in any single static field that is marked as
"self-updating" (or whatever we call it). In windows/dialogs with lots
of fields so marked, the logic might be to wait after the first update
occurs in such a field to see if others likewise update, and then to
make an educated guess about which field is the "title" (easy if the
window title changes!) and automatically read that, or perhaps by
default summarize the changes that occurred in the dialog/window.
Thoughts?
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
On 29 May 2008, at 17:21, Rich Caloggero wrote:
It seems to me that when there is an error condition, someone should
at
least send a sound event or whatever the terminology is in gnome.
Seems like
many people dont' use these, but they do exist and sound files can
be played
when events occur.
This was one of my thoughts too, although I don't know what sort of
shape the sound notification framework in GNOME is in right now. Also
of course, as noted, audio notification is necessary but not
sufficient to make the error completely accessible.
Also seems to me that when a dialog with static text appears,
especially if
it appears due to an error condition, that the static text should be
read
automatically by orca.
I seem to remember Gnopernicus did this for windows of type GtkAlert
(or perhaps it was GtkMessageDialog in those days). Of course, that
doesn't help us here...
Without inventing something like a new text markup tag (or something)
that causes text to be sent to ATs as the same time it's rendered to
the screen, I suppose it's kind of hard for ATs to guess what else is
important enough to read out immediately and what isn't, because
pretty much every dialog contains some static text :/
Cheeri,
Calum.
----- Original Message -----
From: "Rich Burridge" <Rich Burridge Sun COM>
To: "James Westby" <jw+debian jameswestby net>
Cc: "Calum Benson" <Calum Benson Sun COM>; "orca-list" <orca-list gnome org
Sent: Thursday, May 29, 2008 10:26 AM
Subject: Re: [orca-list] PolicyKit
Hi James,
Last week I was attending the Ubuntu Developer Summit, and we had
a session on PolicyKit with the author present. Someone in the
session said that it wasn't very clear when you had entered your
password incorrectly, as the dialog just shakes and clears the
input box. The author said this was clear enough.
Heh. Hopefully he's been enlightened by now. :-)
I just read Rich Burridge's blog post on gnome-screensaver-dialog,
and it seems to confirm my suspicions that the policykit-gnome
dialog isn't accessible.
I'm sorry to say that I know very little about accessibility, but I
would like to help change this. I think we should try and convince
the author to change the design first, but I would like some help
putting a proposal of what should happen together first.
As you will have seen from my post, we have a workaround for now, so
things
will hopefully be better for Orca in GNOME 2.24. We could probably
back-port
this fix for Orca in GNOME 2.22.3.
I suggest involving a good HCI designer in this. I've cc:'ed Calum. If
he's not able to help, hopefully he'll know who will be.
I'm not an HCI person myself, but it seems to me that just leaving the
"Incorrect password" message there, and remove it the moment the user
starts typing again, would really improve things for Orca users.
They'd
use flat-review to explore the dialog and know what's there. That
should
hopefully be a simple fix.
But with a properly designed dialog, things can be a lot better.
Thanks for your interest in this.
On top of this I would like someones idea of how accessible policykit
using applications are. Some applications (e.g. users-admin) grey out
most of the controls and place an unlock button on the dialog to make
them usable. Is it clear how the user should proceed when using orca?
Is there anything the applications could do to make it better, or is
this something that orca scripts would be written for?
Thanks,
James
_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca
_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca
|
