Hey all.
As some of you know, I have been threatening to do this work for a while now, but other things keep bubbling to the top of my priority list. :-/ I'm really sorry about that. Rather than wait until I have everything done, I'm attaching some changes which greatly improve the accessibility of Anaconda for users who are blind and are, insofar as the code goes, pretty trivial.
What the patches do is:
1. Set accessible relations between labels and the things being labeled. As a result, instead of Orca saying things like "text" and leaving the user to guess what text he/she should type, Orca now says "foo: text" and the user knows to type a value for foo. This was also done for labels associated with a group of widgets so that the user has some context when navigating.
Note that there are a couple of ways you can tackle this: Add accessibility-specific code to set the relations or just set the mnemonic widget property and let Gtk do it for you automatically. I wound up doing the latter based on the suggestion of Benjamin Otte (Gtk+ developer).
2. Change initial focus for each* installer step to the likely widget of interest. As a result, instead of Orca merely saying "Next" and leaving the user to wonder what step he/she is on and what is required in order to proceed, Orca now automatically presents the widget and associated context for each new screen/step that appears ("Step foobar, you must enter a foo and a bar, foo text").
* Well, most steps. More work is needed here.
3. Because the change in step 2 in some cases broke the "Just press Return for the 'Next' button" functionality, make the 'Next' button the default. That brings back the "Just press Return" functionality so the end user experience for everyone else should still be the same as it currently is.
If you have any questions, please let me know.
Thanks, take care, and again my apologies for the delay. --joanie (Orca project lead)
On 07/16/2012 10:39 AM, Joanmarie Diggs wrote:
From e451c306dd3a6383226c7567bcf1151b24e4da1e Mon Sep 17 00:00:00 2001
From: Joanmarie Diggsjdiggs@igalia.com Date: Sun, 22 Apr 2012 11:37:43 -0400 Subject: [PATCH 4/5] Establish ATK_RELATION_LABEL_FOR for accessibility
data/ui/account.glade | 1 + data/ui/autopart.glade | 1 + data/ui/cleardisks.glade | 6 +++--- data/ui/filter.glade | 14 ++++++++++++++ data/ui/iscsi-dialogs.glade | 9 +++++++++ data/ui/network.glade | 2 ++ pyanaconda/iw/cleardisks_gui.py | 4 ++++ pyanaconda/iw/language_gui.py | 3 +++ pyanaconda/iw/network_gui.py | 1 + 9 files changed, 38 insertions(+), 3 deletions(-)
Really sorry to say this, but we've been re-writing the UI. There is a newui branch in upstream git where this is happening. All the code in pyanaconda/iw/ is slated to go away, which makes all the patches here not as useful as you would have hoped.
The UI rewrite is still in progress and by no means complete. Chris Lumens is heading up that project and will have more details about what is ready for work and what isn't.
On Monday, 16 July 2012 12:44:07 Jesse Keating wrote:
Really sorry to say this, but we've been re-writing the UI. There is a newui branch in upstream git where this is happening. All the code in pyanaconda/iw/ is slated to go away, which makes all the patches here not as useful as you would have hoped.
Drat. Oh well, life happens....
While the patches are admittedly no longer useful as patches, what the patches do likely still is. Namely, if you want your new UI to be accessible:
1. Most of your labels should programmatically point to the widget they are labeling. The easiest way to do this is set the mnemonic-widget property and let Gtk+ do the accessibility automatically for you.
Related note: If you have a GtkLabel within a container applying to a group of widgets in that container, you can make the container the mnemonic-widget. And you should. That way when users first give focus to a more traditional widget, their screen reader can also present the group label as context.
2. On any given "screen" or step in a wizard, do NOT do a focus grab on the "Next" button. Doing so means that each time a user who is blind goes to the next screen/step, all he or she is told is "Next" because screen readers track and present focus changes. Before too long, the gnome-shell screen magnifier will also track focus changes. As a result, for these users, what they should be viewing may be off screen because the magnifier is showing the "Next" button. Making users have to hunt around to figure out what a screen/step accomplishes and provide the needed info is not especially accessible. This brings me to:
3. On any given "screen" or step in a wizard, DO the focus grab on the first widget. If you have also done item 1 correctly, the result will be that moving from step to step causes screen readers and screen magnifiers to automatically present what the user needs to know.
4. On any given "screen" or step in a wizard, consider making the "Next" button the default. That way, users can still press Return to advance to the next step if no changes are needed in the current one.
5. Be on the lookout for stock widget name conflicts, especially when graphical buttons are being used. One of the advanced steps in Anaconda allows the user to choose which disks should be included in the install, and has the user select drives and then press stock buttons which have left and right arrows to indicate the direction of movement. This makes sense visually; non-visually it does not because the user doesn't see spatially where things are moving. (i.e. that the "don't include" list is on the left and the "do include" is not known because it cannot be seen and is not being stated). This problem is complicated by the fact that the installer as a wizard has a "Back" button and the left-pointing arrow's stock name is "Back". If, in the new UI, that step is going to remain more or less as-is, please change the accessible name of the stock widgets. (I believe this is possible; I've not yet tried it. And that brings me to....)
As you can see, accessible UIs really aren't rocket science. :) Gtk+ gives you quite a bit of accessibility goodness automatically. As you have also seen, my "want to do" items on my TODO list can fall victim to my "must do" items. :( So.... If those of you working on the new UI can keep the above 5 things in mind, you can be ensuring most things are accessible all along the way. Should you have questions as you are doing so, come on by #a11y in irc.gnome.org. I'm usually there (though often idling), ditto for Benjamin Otte who is our resident Gtk+ accessibility expert. Many other Accessibility Team members are typically there as well, and we would all be more than happy to help you sort out any questions or problems you have. Lastly, when you get closer to having the new UI completed and would like someone to give it a spin to be sure it's accessible, please let me know.
Thanks and take care. --joanie
Most of your labels should programmatically point to the widget they are labeling. The easiest way to do this is set the mnemonic-widget property and let Gtk+ do the accessibility automatically for you.
Related note: If you have a GtkLabel within a container applying to a group of widgets in that container, you can make the container the mnemonic-widget. And you should. That way when users first give focus to a more traditional widget, their screen reader can also present the group label as context.
I don't quite follow. All our glade files for the newui are up at http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/ui/gui/spokes. Could you give me an example of where we are/aren't doing the right thing?
- On any given "screen" or step in a wizard, do NOT do a focus grab on the "Next" button. Doing so means that each time a user who is blind goes to the next screen/step, all he or she is told is "Next" because screen readers track and present focus changes. Before too long, the gnome-shell screen magnifier will also track focus changes. As a result, for these users, what they should be viewing may be off screen because the magnifier is showing the "Next" button. Making users have to hunt around to figure out what a screen/step accomplishes and provide the needed info is not especially accessible. This brings me to:
We only have a Next button in a palce or two now and we never have it grab the focus. I don't think this should be a problems.
- On any given "screen" or step in a wizard, DO the focus grab on the first widget. If you have also done item 1 correctly, the result will be that moving from step to step causes screen readers and screen magnifiers to automatically present what the user needs to know.
Hm, we're not doing anything special here so it might need work. We're just letting gtk/glade/whatever do what it wants to do by default.
- On any given "screen" or step in a wizard, consider making the "Next" button the default. That way, users can still press Return to advance to the next step if no changes are needed in the current one.
Our new UI flow has you only go into screens that you want to go into, so I think we've taken care of this item just by nature of how things are organized now.
- Be on the lookout for stock widget name conflicts, especially when graphical buttons are being used. One of the advanced steps in Anaconda allows the user to choose which disks should be included in the install, and has the user select drives and then press stock buttons which have left and right arrows to indicate the direction of movement. This makes sense visually; non-visually it does not because the user doesn't see spatially where things are moving. (i.e. that the "don't include" list is on the left and the "do include" is not known because it cannot be seen and is not being stated). This problem is complicated by the fact that the installer as a wizard has a "Back" button and the left-pointing arrow's stock name is "Back". If, in the new UI, that step is going to remain more or less as-is, please change the accessible name of the stock widgets. (I believe this is possible; I've not yet tried it. And that brings me to....)
I think the only place we're doing any sort of arrow buttons right now is up/down in the keyboard layout spoke. This is for changing the priority of layouts. Should I change the accessible name of the button, or the image contained in the button? And what makes a good name?
There are a couple places we're using plus and minus signs for buttons. Are those okay, or do I need to do things to them?
Lastly, when you get closer to having the new UI completed and would like someone to give it a spin to be sure it's accessible, please let me know.
Be on the lookout for F18 Alpha, which will contain the new UI. Or if you are feeling more adventerous (meaning, you have a VM or computer whose contents you do not care about) I can point you at a test image. I'd definitely be interested in hearing your feedback as this is an important part of the newui work.
- Chris
anaconda-devel@lists.stg.fedoraproject.org