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
