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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list