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.
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 firstname.lastname@example.org – they would love to help you.