Re: [g-a-devel] [orca-list] PolicyKit

[Willie Walker <William Walker Sun COM>]

Hi All:

The ARIA live-region concept might be applicable here:

http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions

With respect to automatically reading static text, Orca has some code to 
do this, and it does so in a number of places.  We 'dialed down' the 
aggressiveness of Orca's approach to this, however, because we found it 
ended up being very very chatty, especially when faced with UI's created 
by developers who neglected to bind labels with the things they were 
labelling.

Will

Peter Korn wrote:
> 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
> > >
> > >     
> >
> >   
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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