This morning at the GNOME 3 UX Hackfest in London, Willie Walker gave us some tips for ‘painless’ accessibility.
First he reviewed the three main types of access users need us to support:
1: Some people can’t use the keyboard
These users use devices such as:
- head tracking
- eye tracking
- switch-based access (they press buttons on a switch – the accessibility layer translates these to keyboard stroke)
For head-tracking and eye-tracking, they hover over an area to cause a click. Some of these users can’t use keyboard or mouse at all. They may use a button/switch to interact and translate to keyboard.
You need to think about users who cannot use the keyboard at all.
2: Some people can’t use the mouse
These users use devices such as:
- switch-based access (they press buttons on a switch
- use joystick instead of mouse
A big category of users who cannot use the mouse are users who are completely blind. Since they cannot tell where on the screen the mouse is, they can’t use it. These users rely on keyboard access
To make sure you’re accounting for these users, try unplugging your mouse and see if you can use your interface:
- Can you get to all the functionality?
- Can you get to all the functionality efficiently How many keystrokes will it take??
3: Some people who can’t see the screen.
Users in this category:
- May be visually impaired with respect to their perception of colors. For some, particular color contrasts may be quite painful.
- May be visually impaired with respect to their ability to read text on the screeen.
- May be completely blind.
Design Implications
GNOME handles the presentation of content for users who are visually-impaired:
- Font-sizes and icon-sizes are adjustable.
- High-contrast themes are available.
- Screen magnification is possible. (no special design considerations needed here.)
- Reducing the screen output to text-only: screen readers that output both via audio and via Braille displays.
Here’s some tips for GNOME designers and developers to help ensure your design is more accessible:
- Make sure there isn’t any functionality available via the keyboard only.
- Be wary that your color choices might not be good for everyone and there should be a good way to override them. Whenever possible, pull your colors from the GNOME theme. Your colors should not be hard-coded, and must be override-able.
Yes, your interface may not appear in colors that are in your brand book or evoke the emotion you wish to convey in your interface – but consider that the ability for someone to be able to use your software or not be able to use it at all also affects your brand as well. - Be redundant in how you broadcast your design – for example, please do not rely on color as the sole or primary way to help users differentiate between two elements/modes/etc. of an interface. Have other elements of the design (position, labels, etc.) indicate this as well.
- Please be wary of custom toolkits/ widgets – they do not typically support accessibility. If you must use them, ask your developer to build accessibility into any custom widgets they may be writing for you.
- If areas of the interface do not have text (for example, a search area that is not labeled ‘search’), make sure you’re using the accessibility labels and descriptions. In glade, you can set these via the accessibility tab (it has a blue wheelchair icon.) Translators will be able to access these and translate them as well! They won’t appear in the interface but will be made available to the screen reader.
- When coming up with textual equivalents to interface elements:
- Imagine someone speaking them aloud to you. You don’t want War and Peace every time you happen to highlight a UI element. Make them clear and succinct.
- Think about differentiation. You don’t want to repeat the same string for every single item in a menu, for example – you want the differentiating text to come first. (Willie gave the example of a menu where the user hears ‘menu item new’, ‘menu item save’, ‘menu item open’, etc. etc. while navigating through. The info that helps the user differentiate between each item comes last – that makes it more difficult to use.)
- Try to reduce chattiness. People get annoyed with chatty screen-readers. (To this end, orca even has a ‘shut up’ key.)
- “Type into this field to perform a search” == BAD label. “Search’ == good label.
- Anything you can do to reduce keystrokes is really good for users who cannot use the mouse.
- This is common-sense anyway, but when designing keyboard shortcuts for your interface, make sure the ‘chording’ of the keystrokes is reasonable to access. E.g., don’t require users to play a fun game of twister and have to hit 6 keys at the same time! 🙂
- Mnemonics in GTK+ not only give users a visible keyboard shortcut to access a particular element of a UI, they automagically bind labels and form fields together, creating an association that also helps users associate the two elements together. Consider than while visually positioning elements together creates a relationship between them implicitly, there are users who do not have visual access and tools like mnemonics which explicitly associate the two UI elements are vital for those users who cannot visually discern the relationship.
- Use GTK frame widgets to group related areas of the interface together under a common label. This enables users to navigate between entire sections of UI rather than just field-by-field. Also, make sure you implement this using the GTK frame widget rather than just a label with indented widgets underneath it – the GTK frame widget actually creates an association between the frame label and the widgets below it that is not there if you implement it in looks but not in ‘spirit.’
- Wizard design: don’t keep focus on the next button! This might be the default behavior if you use glade, but it wastes the user’s time because they need to navigate above the next button – why not save them the keystroke? Also, this ensures that when a user lands on the next screen, that it starts off by reading the first item on the screen rather than ‘next’ (image going through a wizard, clicking ‘next’ to go to the next screen, and the computer tells you, ‘next’ on the following screen – how disorienting!
Calum asked Willie a really good question – how do assistive technologies handle dynamic UI elements? As Willie explained, we handle it okay but we could do better. Some common dynamic UI elements are progress bars, or monitoring graphs (eg the CPU usage monitor), or checkboxes that disable based on selections elsewhere on the screen. For the latter case – dynamically-disabled elements – when they are disabled, they are not accessible until the selections on the screen enable it again, so this case is handled okay. For progress bars and graphics, one thing we can do is announce every time it changes, or we can put some time constraints in there for announcement – announce every 3-5 seconds, for example. For progress bars in particular, we have a progress bar setting for orca: announce updates (yes or no.) This enables orca to announce every so many seconds the current status of the progress bar. For example, for a download progress bar: “10 percent. 25 percent. 73 percent.” We could handle these better, though.
So how accessible is your UI?
Willie put together a great Accessibility Smoke Testing Plan that you can run through to see how your UI stacks up for accessibility. The five steps summarized (please read Willie’s plan for the full version of these!):
- Unplug your mouse. Is your UI usable?
- Select the GNOME ‘High Contrast Theme’ and examine your UI for color and font changes.
- Check your app out in Accerciser.
- Check out your custom widgets in Accerciser.
- Try your UI in Orca.
A little bit about how GNOME Assistive Technologies Work
- AT-SPI provides the ability for an external app (e.g. Orca and other assistive technologies) to look at the widget hierarchy and register for changes in that hierarcy. ‘let me know if something changes focus here.’
- GTK+ has something called gail (GNOME Accessibility Implementation Layer) – it turns GTK widgets into AT-SPI. Gail has an implementation for every widget in GTK. When you create a brand-new, custom widget you need to create a similar gail implementation for it to be accessible. You can test it via Accerciser.
How to learn more
- The GNOME Accessibility Developers’ Guide is a handy reference for developers to learn more about how to make their applications more accessible.
- Look at similar widgets or applications in GNOME to see how they implement accessibility.
- Mail the GNOME accessibility team at gnome-accessiblity-list@gnome.org – they would love to help you.
Lovely, clear piece!
Tks Mairin.
Thank you! As a clueless developer I sometimes feel pangs of conscience reminding me that I should be thinking/doing something about accessibility, but they usually pass away before I can find a checklist of things to do. Bookmarked.
A 4th category is those with cognitive disabilities who can't handle too much complexity in information presentation or interaction. The answer is 'keep it simple' or the old KISS principle. Applies largely to information architecture design, and layout.
Thanks for the relay, Máirín. It's nice to hear that accessibility is being discussed at the UX hackfest.
I'm curious about the "use GTK+ frame widgets" part. The trend (supported by the HIG, IIRC) throughout 2.x has been not to use frame widgets, but to use judicious spacing instead. We like the look. So what's a poor developer to do?
I wonder if we could get the frame widget in GTK+ to have a "display using padding only" setting, so we could get the same UI (and probably easier) with all the accessible goodness.
Shaun, the latest GtkFrame no longer shows the "frames", the label is bold and provides by default a 12 pixels intent (at least in glade-3). However, the 6 top pixels between bold label and first child widget should be added manually, it seems there is a spurious 1 pixel all around and I'm sure there are some issues with widgets backgrounds.
I've just opened bug 611004 asking for a good solution for both design and a11y for 3.0
As a fully capable user and hacker who nevertheless prefers the keyboard over the mouse, I appreciate these efforts as well.
Great writeup! Go Willie!
I am confused by:
Anything you can do to reduce keystrokes is really good for users who cannot use the mouse.
Can you give an example of this as it seems counter intuitive.. in that if the mouse is not being used then the keyboard or similar method would be in use.
thanks
smooge, by keystrokes it's meant the chain of keystrokes necessary to access a function. e.g., if to delete a email i must keystroke:
alt+f > down key > down key > down key > right arrow > right arrow > enter > enter
that's a lot of keystrokes vs one mouse click
And some people can't hear beeps. 😉
Although honestly, for desktop apps, this tends to be more a convenience/"am I annoying people with beeps I can't hear?" factor than a "renders program utterly unusable" one, at least for me. IMO, the place in FOSS where accessibility for the deaf and hard-of-hearing really makes a difference is the web (videos and podcasts not having captions, etc).
Category 3 was ignored when Gnome decided to remove most of the icons from many apps, leaving only text labels. I think that this should be a choice, so that people who really need, or want, the visual cues provided by the icons could benefit, while those who find both a text label and an icon to be clutter that takes up valuable screen area can turn them off.
While Gnome has generally tried to avoid having too many configuration options, for accessibility issues there really isn't any choice, because there are those who only benefit from the text, and there are those who only benefit from the icons.
[…] Painless accessibility tips for GNOME designers and developers « Máirín Duffy […]
[…] Máirín’s writeup about the accessibility discussions at the UX hackfest really made me happy. So glad Willie Walker made it there, I thought of going, but Willie really knows how to drive a point home. […]
For giving an indication of progress bars for visually-impaired, I was reminded of how Psychonauts indicated "closeness" to a "deep-arrowhead" when using the "dousing rod" is indicated by the pitch of a continuously-emitted sound. As you get really closer to a "deep-arrowhead", the pitch increases, and you know intuitively that you're getting closer to it.
Perhaps something similar could be implemented for progress bars (of course, people might find it irritating, so it should be configurable, and default off, preferably.)
My baby ensures I fit into category 1 on most days…
Hiya mo. something away from the topic..
what's the tool that you can see on the laptop screen in the second image in the post, in the lower left corner of the image…
looks unusually colorful… (It's not outlook, is it?)
I actually have no idea. That's not my laptop.
[…] Painless accessibility tips for GNOME designers and developers This morning at the GNOME 3 UX Hackfest in London, Willie Walker gave us some tips for ‘painless’ accessibility. […]
[…] Painless accessibility tips for GNOME designers and developers « Máirín Duffy […]
[…] Painless accessibility tips for GNOME designers and developers « Máirín Duffy […]
Great writeup, Do you have the recording of the sessions online ?
Unfortunately as far as I know none of these sessions have been recorded. 🙁
[…] to spend some time talking to the group informally about “painless accessibility”. Máirín Duffy from Red Hat blogged about the talk and it touched me deeply — she “got it”. In addition, Matthew […]