Re: [g-a-devel] [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

    

  



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]