headers
Peter Korn | 3 Jun 2008 20:13
Picon

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 <at> Sun.COM> To: "James Westby" <jw+debian <at> jameswestby.net> Cc: "Calum Benson" <Calum.Benson <at> Sun.COM>; "orca-list" <orca-list <at> 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 <at> 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 <at> gnome.org http://mail.gnome.org/mailman/listinfo/orca-list Visit http://live.gnome.org/Orca for more information on Orca 

_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Permalink | Reply | 2 comments |
headers
Willie Walker | 3 Jun 2008 21:18
Picon

Re: [orca-list] PolicyKit

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 <at> Sun.COM>
>>> To: "James Westby" <jw+debian <at> jameswestby.net>
>>> Cc: "Calum Benson" <Calum.Benson <at> Sun.COM>; "orca-list" <orca-list <at> 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 <at> 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 <at> 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 <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/orca-list
> Visit http://live.gnome.org/Orca for more information on Orca
Permalink | Reply | 0 comments |
headers
Willie Walker | 4 Jun 2008 22:28
Picon

Re: startup of a11y tools

Now that this bug has been fixed for 2.24, we may have gotten rid of one 
of the last remaining barriers to enabling a11y by default:

   http://bugzilla.gnome.org/show_bug.cgi?id=524263

Will

Peter Korn wrote:
> Hey Willie,
> 
> Regarding #5 below - enabling accessibility on the desktop: I think it 
> is worth asking the question whether we are ready to have desktop 
> accessibility support on by default.  It takes more memory, so we 
> certainly want to allow folks to turn it off if they don't need it.  And 
> in the past it was more unstable than any of us liked (and so folks who 
> didn't need it wanted it off by default).  But... it is being used more 
> and more by folks doing testing of GUIs in general (thanks to dogtail, 
> et. al.) and it has been getting a lot more testing in general.
> 
> So, maybe for GNOME 2.24 this would be a possibility?
> 
> 
> Regards,
> 
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
> 
>> I agree that things are a little confusing right now. I'm not sure I've 
>> fully understood/appreciated the motivation for why things are the way 
>> they currently are.  This might be a good opportunity to clarify, 
>> improve, or both. :-)
>>
>> I think there are a bunch of different problems to think about:
>>
>> 0) How do I know what accessibility solutions GNOME offers?  These 
>> include global system preferences (e.g., AccessX and theming) as well as 
>> assistive technologies (e.g., Orca, GOK, Dasher, MouseTweaks).  One 
>> solution is word-of-mouth, which should not be discounted as a 
>> reasonable solution.  Another solution is to read the documentation, 
>> which we are improving as part of GOPA.  Another is to scour the 
>> "Applications" menu to see what's there (i.e., the same way I'd stumble 
>> across an e-mail client or web browser).  Another is to scour the 
>> "Preferences" menu for assistive technology preferences.  This all seems 
>> like it could be cleaner.
>>
>> 1) How do I enable theming and/or AccessX features on the login screen? 
>>     For theming, I believe the current solution is to offer an optional 
>> menu on the username/password dialog, which is OK.  For AccessX, the 
>> current solution is to make sure AccessX is enabled in the X server and 
>> to rely upon the de facto settings and keyboard gestures built in the 
>> XKB server extension.  This is marginally OK, and tends to be the 
>> solution we see on public information kiosks (i.e., you don't get your 
>> exact personal preferences, but you should get enough to allow you to 
>> log in).
>>
>> 2) How do I launch an assistive technology from the login screen?  While 
>> it requires a one-time sysadmin operation to enable accessible login, 
>> the current solution of keyboard and/or mouse gestures for gdm seems to 
>> be reasonable for many users.  Doing so requires a priori knowledge of 
>> the keyboard/mouse gestures, but perhaps some automatic 'help' content 
>> generation might be possible?  In addition, a dialog as suggested in the 
>> kick off for this thread might help some users as long as they do not 
>> need an assistive technology to access the dialog.
>>
>> 3) How do I 'carry over' accessibility from the login screen to the 
>> desktop session?  The current solution is to treat the gdm session and 
>> the desktop session as separate.  This presents an issue for users until 
>> they've customized their desktop session for accessibility.  That is, 
>> the solution is that there is no carry over and that the user needs to 
>> customize their desktop session for accessibility.
>>
>> 4) Related to #3, there are at least two solutions for autostarting 
>> assistive technologies: general autostart for GNOME and a special 
>> "Accessibility" tab on the preferred applications dialog 
>> (gnome-default-applications-properties).  The overlap of these has been 
>> a source of confusion to me.  For simplicity, it has seemed to me that 
>> the assistive technology itself should be the one to offer the "start me 
>> on log in" option, and it should do so by just adding itself to the 
>> general autostart list for GNOME.
>>
>> 5) Related to #3, how do I enable a11y for the desktop?  The current 
>> solution is to provide the a11y preferences dialog for this.  IMO, this 
>> is kind of counterintuitive and is probably something that should 
>> instead be provided by the tool that requires the a11y infrastructure to 
>> be enabled (e.g., Orca, GOK, DogTail, etc.).
>>
>> 6) Related to #2, can I create a customized a11y environment for gdm? 
>> That is, always set the theme by default, always enable SlowKeys with a 
>> timeout of 0.75 seconds, etc.  I have no great answer for this since 
>> I've always been accustomed to the login screen being a shared system 
>> resource on a multiuser system.  :-(
>>
>> In any case, I think this is a good discussion.  We definitely have room 
>> for improvement/clarity.
>>
>> Will
>>
>> Brian Cameron wrote:
>>   
>>> Matthias:
>>>
>>>     
>>>> Imo an approach like the one taken by Jon McCann in the new gdm a11y
>>>> dialog (see  http://live.gnome.org/GDM/Screenshots ) is much more
>>>> straightforward and we should look at doing something similar inside
>>>> the session.
>>>>       
>>> I agree that the new dialog is a big step forward.  It is a good idea
>>> to provide a user-visible dialog where users can select the a11y
>>> programs they wish to run.
>>>
>>> However, this interface is lacking because many users with disabilities
>>> simply cannot navigate the GUI to begin with unless the a11y programs
>>> they need are already running.  A chicken-and-egg problem.
>>>
>>> I know the new GDM does support the ability to always launch (autostart)
>>> additional programs, which can be used to start a11y programs along with
>>> GDM.  This perhaps meets the needs of a single-user desktop.  However,
>>> this doesn't work well on multi-user desktops or terminal server
>>> settings where some users may need text-to-speech, others may need
>>> magnification, and others might not need any additional a11y programs to
>>> be running.
>>>
>>> I think this "support a11y on multi-user servers for users who may have
>>> different a11y needs" is an important use case that should be addressed
>>> before a general solution be implemented into the GNOME desktop.
>>>
>>> Brian
>>> _______________________________________________
>>> Gnome-accessibility-devel mailing list
>>> Gnome-accessibility-devel <at> gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>>>     
>> _______________________________________________
>> Gnome-accessibility-devel mailing list
>> Gnome-accessibility-devel <at> gnome.org
>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>>   
>
Permalink | Reply | 2 comments |
headers
Jason White | 5 Jun 2008 02:32

Re: startup of a11y tools

On Wed, Jun 04, 2008 at 04:28:04PM -0400, Willie Walker wrote:
> Now that this bug has been fixed for 2.24, we may have gotten rid of one 
> of the last remaining barriers to enabling a11y by default:
> 
>    http://bugzilla.gnome.org/show_bug.cgi?id=524263

This is great news. Thanks to all involved.

This bug has been annoying me more than any other, since my laptop quite often
fails to load the AT-SPI registry on time, and all I can do is type
ctrl-alt-backspace to kill the X server and try again.

The machine isn't particularly slow (a 1.8ghz AMD Athlon64 CPU, 1gb RAM), but
it uses CPU frequency scaling, and the hard drive is probably only a 5400 rpm
IDE disk.
Permalink | Reply | 1 comment |
headers
Steve Lee | 5 Jun 2008 14:23
Picon
Favicon

Re: startup of a11y tools

Excellent. That bugged me if I waited after power up before logging on
but I couldn't repro on demand. I discussed with Ubuntu (Luke?) but we
got nowhere so really pleased it's been fixed. Way cool I have no
other issues with a11y on all the time. ;-)

-- 
Steve Lee
--
Open Source Assistive Technology Software
web: fullmeasure.co.uk
blog: eduspaces.net/stevelee/weblog

On 04/06/2008, Willie Walker <William.Walker <at> sun.com> wrote:
> Now that this bug has been fixed for 2.24, we may have gotten rid of one
>  of the last remaining barriers to enabling a11y by default:
>
>    http://bugzilla.gnome.org/show_bug.cgi?id=524263
>
>  Will
>
>
>  Peter Korn wrote:
>  > Hey Willie,
>  >
>  > Regarding #5 below - enabling accessibility on the desktop: I think it
>  > is worth asking the question whether we are ready to have desktop
>  > accessibility support on by default.  It takes more memory, so we
>  > certainly want to allow folks to turn it off if they don't need it.  And
>  > in the past it was more unstable than any of us liked (and so folks who
>  > didn't need it wanted it off by default).  But... it is being used more
>  > and more by folks doing testing of GUIs in general (thanks to dogtail,
>  > et. al.) and it has been getting a lot more testing in general.
>  >
>  > So, maybe for GNOME 2.24 this would be a possibility?
>  >
>  >
>  > Regards,
>  >
>  > Peter Korn
>  > Accessibility Architect,
>  > Sun Microsystems, Inc.
>  >
>  >> I agree that things are a little confusing right now. I'm not sure I've
>  >> fully understood/appreciated the motivation for why things are the way
>  >> they currently are.  This might be a good opportunity to clarify,
>  >> improve, or both. :-)
>  >>
>  >> I think there are a bunch of different problems to think about:
>  >>
>  >> 0) How do I know what accessibility solutions GNOME offers?  These
>  >> include global system preferences (e.g., AccessX and theming) as well as
>  >> assistive technologies (e.g., Orca, GOK, Dasher, MouseTweaks).  One
>  >> solution is word-of-mouth, which should not be discounted as a
>  >> reasonable solution.  Another solution is to read the documentation,
>  >> which we are improving as part of GOPA.  Another is to scour the
>  >> "Applications" menu to see what's there (i.e., the same way I'd stumble
>  >> across an e-mail client or web browser).  Another is to scour the
>  >> "Preferences" menu for assistive technology preferences.  This all seems
>  >> like it could be cleaner.
>  >>
>  >> 1) How do I enable theming and/or AccessX features on the login screen?
>  >>     For theming, I believe the current solution is to offer an optional
>  >> menu on the username/password dialog, which is OK.  For AccessX, the
>  >> current solution is to make sure AccessX is enabled in the X server and
>  >> to rely upon the de facto settings and keyboard gestures built in the
>  >> XKB server extension.  This is marginally OK, and tends to be the
>  >> solution we see on public information kiosks (i.e., you don't get your
>  >> exact personal preferences, but you should get enough to allow you to
>  >> log in).
>  >>
>  >> 2) How do I launch an assistive technology from the login screen?  While
>  >> it requires a one-time sysadmin operation to enable accessible login,
>  >> the current solution of keyboard and/or mouse gestures for gdm seems to
>  >> be reasonable for many users.  Doing so requires a priori knowledge of
>  >> the keyboard/mouse gestures, but perhaps some automatic 'help' content
>  >> generation might be possible?  In addition, a dialog as suggested in the
>  >> kick off for this thread might help some users as long as they do not
>  >> need an assistive technology to access the dialog.
>  >>
>  >> 3) How do I 'carry over' accessibility from the login screen to the
>  >> desktop session?  The current solution is to treat the gdm session and
>  >> the desktop session as separate.  This presents an issue for users until
>  >> they've customized their desktop session for accessibility.  That is,
>  >> the solution is that there is no carry over and that the user needs to
>  >> customize their desktop session for accessibility.
>  >>
>  >> 4) Related to #3, there are at least two solutions for autostarting
>  >> assistive technologies: general autostart for GNOME and a special
>  >> "Accessibility" tab on the preferred applications dialog
>  >> (gnome-default-applications-properties).  The overlap of these has been
>  >> a source of confusion to me.  For simplicity, it has seemed to me that
>  >> the assistive technology itself should be the one to offer the "start me
>  >> on log in" option, and it should do so by just adding itself to the
>  >> general autostart list for GNOME.
>  >>
>  >> 5) Related to #3, how do I enable a11y for the desktop?  The current
>  >> solution is to provide the a11y preferences dialog for this.  IMO, this
>  >> is kind of counterintuitive and is probably something that should
>  >> instead be provided by the tool that requires the a11y infrastructure to
>  >> be enabled (e.g., Orca, GOK, DogTail, etc.).
>  >>
>  >> 6) Related to #2, can I create a customized a11y environment for gdm?
>  >> That is, always set the theme by default, always enable SlowKeys with a
>  >> timeout of 0.75 seconds, etc.  I have no great answer for this since
>  >> I've always been accustomed to the login screen being a shared system
>  >> resource on a multiuser system.  :-(
>  >>
>  >> In any case, I think this is a good discussion.  We definitely have room
>  >> for improvement/clarity.
>  >>
>  >> Will
>  >>
>  >> Brian Cameron wrote:
>  >>
>  >>> Matthias:
>  >>>
>  >>>
>  >>>> Imo an approach like the one taken by Jon McCann in the new gdm a11y
>  >>>> dialog (see  http://live.gnome.org/GDM/Screenshots ) is much more
>  >>>> straightforward and we should look at doing something similar inside
>  >>>> the session.
>  >>>>
>  >>> I agree that the new dialog is a big step forward.  It is a good idea
>  >>> to provide a user-visible dialog where users can select the a11y
>  >>> programs they wish to run.
>  >>>
>  >>> However, this interface is lacking because many users with disabilities
>  >>> simply cannot navigate the GUI to begin with unless the a11y programs
>  >>> they need are already running.  A chicken-and-egg problem.
>  >>>
>  >>> I know the new GDM does support the ability to always launch (autostart)
>  >>> additional programs, which can be used to start a11y programs along with
>  >>> GDM.  This perhaps meets the needs of a single-user desktop.  However,
>  >>> this doesn't work well on multi-user desktops or terminal server
>  >>> settings where some users may need text-to-speech, others may need
>  >>> magnification, and others might not need any additional a11y programs to
>  >>> be running.
>  >>>
>  >>> I think this "support a11y on multi-user servers for users who may have
>  >>> different a11y needs" is an important use case that should be addressed
>  >>> before a general solution be implemented into the GNOME desktop.
>  >>>
>  >>> Brian
>  >>> _______________________________________________
>  >>> Gnome-accessibility-devel mailing list
>  >>> Gnome-accessibility-devel <at> gnome.org
>  >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>  >>>
>  >> _______________________________________________
>  >> Gnome-accessibility-devel mailing list
>  >> Gnome-accessibility-devel <at> gnome.org
>  >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>  >>
>  >
>
>  _______________________________________________
>  Gnome-accessibility-devel mailing list
>  Gnome-accessibility-devel <at> gnome.org
>  http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>

On 05/06/2008, Jason White <jason <at> jasonjgw.net> wrote:
> On Wed, Jun 04, 2008 at 04:28:04PM -0400, Willie Walker wrote:
>  > Now that this bug has been fixed for 2.24, we may have gotten rid of one
>  > of the last remaining barriers to enabling a11y by default:
>  >
>  >    http://bugzilla.gnome.org/show_bug.cgi?id=524263
>
>
> This is great news. Thanks to all involved.
>
>  This bug has been annoying me more than any other, since my laptop quite often
>  fails to load the AT-SPI registry on time, and all I can do is type
>  ctrl-alt-backspace to kill the X server and try again.
>
>  The machine isn't particularly slow (a 1.8ghz AMD Athlon64 CPU, 1gb RAM), but
>  it uses CPU frequency scaling, and the hard drive is probably only a 5400 rpm
>  IDE disk.
>
>
>  _______________________________________________
>  Gnome-accessibility-devel mailing list
>  Gnome-accessibility-devel <at> gnome.org
>  http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>

--

-- 
Steve Lee
--
Open Source Assistive Technology Software
web: fullmeasure.co.uk
blog: eduspaces.net/stevelee/weblog
Permalink | Reply | 0 comments |
headers
Rich Caloggero | 4 Jun 2008 02:46
Picon
Favicon

Re: [orca-list] PolicyKit

>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 -----
From: Peter Korn
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 <at> Sun.COM> To: "James Westby" <jw+debian <at> jameswestby.net> Cc: "Calum Benson" <Calum.Benson <at> Sun.COM>; "orca-list" <orca-list <at> 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 <at> 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 <at> gnome.org http://mail.gnome.org/mailman/listinfo/orca-list Visit http://live.gnome.org/Orca for more information on Orca 

_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Permalink | Reply | 0 comments |

Gmane