|
>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,
This sounds worth at least testing out to see it
improves things, or becomes too chatty, etc. Even if the screen reader
doesn't respond to the state directly, it could be a huge win for custom
scripts which, having more knowledge of the local app, can use the new state
more wisely.
Just my two cents...
-- Rich
----- Original Message -----
Sent: Tuesday, June 03, 2008 2:13
PM
Subject: Re: [orca-list] PolicyKit
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
|
