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