One of our primary design objectives for the rewrite of GDM was to have accessibility features be well integrated with the login screen (known as the greeter) and available by default. The previous GDM supported accessibility, but not by default. A disabled user needed someone to pre-configure the system to support accessibility at all. See the GDM 2.20 documentation for details. We wanted to do better than that and, ideally, to make the experience and controls on the login screen consistent with those in the user’s GNOME desktop session.
The first question we needed to answer was: how does the user enable accessibility features? So, first, we took a look at how this works in the user’s desktop session.
If the user is persistent they may find the Assistive Technologies dialog in the GNOME Preferences menu. It looks something like this:
Even if the user is able to read or navigate this dialog (accessibility features are off at this point) they may not really know what to do here. Hopefully, she will know that to be able to use most accessibility tools the “Enable assistive technologies” option must be enabled, and that she must logout and log back in before it will take effect. [1]
After the next login the assistive technology framework will be enabled but she still has not started any tools to take advantage of it. To do that she’ll need to go back to the Assistive Technologies Preferences dialog and set these up. To configure tools like a screen-reader, magnifier, etc. she’ll need to click the Preferred Applications button. And will get a dialog that looks like this:
Assuming that she is able to actually read and navigate this dialog, the first thing she’ll need to determine is which disability class she falls into, Visual or Mobility. The next thing she must do is determine which tool she prefers. On my system, the options available for Visual tool are: Orca, Orca with Magnifier, GNOME Magnifier without Screen Reader, and Custom. And the options for Mobility are typically: GNOME OnScreen Keyboard, Dasher, and Custom. The options have no effect unless the “Run at Start” option is enabled and even then it only takes effect on the next login.
She may also need assistance using the keyboard. For this she’ll need to click on the “Keyboard Accessibility” button on the “Assistive Technologies Preferences” dialog. It will bring up a dialog like this:
This dialog allows her to enable the Sticky Keys, Slow Keys, or Bounce Keys features as well as the keyboard shortcuts for them. The following keyboard shortcuts may be used:
- Press-and-hold Shift for eight seconds to enable or disable the slow keys feature.
- Press Shift five times to enable or disable the sticky keys feature.
These keyboard shortcuts or gestures are quite useful. They allow the user to change the behavior of the keyboard directly without the need to navigate to the preferences dialog (which may be very difficult for some people). However, if this keyboard shortcut is used accidentally by an unwitting user the results can be extremely bad. In fact, the user may consider the computer broken. [2] Therefore, we make an attempt to alert the user when the behavior of the keyboard has changed dramatically. When Slow Keys is activated using the keyboard shortcut we pop up the following dialog:
And for Sticky Keys:
Again, the intended audience for these dialogs is not the user who knowingly activates the accessibility feature but rather the user who accidentally activates it. However, for that purpose they are entirely inadequate. There are two basic problems with this approach. First, due to focus-stealing-prevention the dialog will most likely be placed behind the currently used window and therefore will not be visible. Second, once the dialog is dismissed there is not further indication that the behavior of the system is significantly changed.
That is how it works now in the user’s GNOME desktop session.
Unfortunately, this manner of operation is incompatible with the login screen.
For the login screen we must have:
- No required pre-configuration
- Accessibility enabled by default
- No ability to define “custom” tools by specifying an arbitrary command line (for security)
- Well known shortcuts that have well known actions
- Ability to enable features at a finer level of granularity than Visual/Mobility
- An obvious indication when the keyboard/input behavior has changed
- A quick way to enable and disable accessibility features
And ideally we would have some consistency in experience and controls between the login screen and the user’s session. This is particularly important when the user doesn’t already know the state the computer is in (ie. if a user’s GNOME desktop session is currently active or the login window is active, etc.).
Since the approach used in the current GNOME session is inadequate for the login screen, for GDM 2.22 we went with an approach that is similar to one used on the Windows Vista login screen:
So far, this seems to work relatively well. However, we still have very different configuration mechanisms at the login screen and in the user’s GNOME session. We also received some complaints from users who had grown accustomed to the way the old GDM worked. We should have a better story and we needed some expert advice.
So after a few conversations about these issues in the GNOME #a11y IRC channel, Will Walker offered to come down to the Red Hat office in Westford for an informal face-to-face meet-up. Last week we took him up on the offer. Will met with a few of us from the Desktop Team (Ray, Matthias, David, and me). It was great to meet Will in person and I think it was very productive.
Will gave us a nice overview of the problem space, including descriptions of the various impairments that we try to address. One of the things that really struck me was when he talked about empowering the user and how disabled users have the right to be independent and capable of using their computer without someone else helping them along or configuring it for them. I think that is a pretty powerful idea. And, actually, one that (at least to me) is pretty much at the core of GNOME.
During the conversation with Will I think we were able to agree on some core values for our work in this space:
- Promote the independence of the user
- Make it accessible to all by default
- Provide a consistent experience and well known controls
So what does that mean?
- We should make things “Just Work”. We should make sure that people can do the things they need to do without someone else helping them.
- This is about more than simply enabling accessibility features. This means making sure that anyone can sit down at any GNOME system and operate it. One side of this is making it easy for a disabled user to enable the accessibility tools they need. The other side is making sure that we properly indicate when accessibility tools have modified the behavior of the system and provide easy ways to disable those same features.
- We should probably aim to unify the interfaces provided at the login screen and in the user’s GNOME desktop session. We should also establish a set of well known shortcuts and associated actions that may be used at any time.
One proposal for how to move toward these goals is to take advantage of the gnome-settings-daemon that is used by both the new GDM login screen and the user’s GNOME desktop session. This daemon already handles the “AccessX” keys (Sticky, Slow, and Bounce) and displays the warning dialogs that I mentioned before.
When the keyboard shortcuts are enabled we could display a status icon in the notification area.
And, for example, when the keyboard shortcut for Slow Keys is used we could display a bubble giving the user the option to turn it off:
We could also use some of the ideas from the current accessibility applet and change the icon to indicate the current Slow Keys state.
When the user clicks on the status icon we could show a simple version of the preferences dialog that could look something like this:
□ Enable Screen Reader
□ Enable Screen Magnifier
□ Enable On-Screen Keyboard
□ Enable Predictive Input and Control
□ See more contrast in colors (High Contrast)
□ Press keyboard shortcuts one key at a time (Sticky Keys)
□ Ignore duplicate keypresses (Bounce Keys)
□ Only accept long held keypresses (Slow Keys)
□ Use a larger font size (Large Print)
□ Use visual cues for sounds (Visual Sounds)
□ Use alternate mouse gestures (Mouse Tweaks)
[ Close ]
Some things we were uncertain about were:
- What is the relationship between GOK and Dasher?
- How can we best represent the dasher option? (Predictive Input… isn’t so hot)
- Is GOK a reasonable virtual keyboard to support the tablet PC use case?
- Is there a way to combine Dasher and GOK?
- Should we show a button to launch a tool to perform more detailed configuration of these tasks?
- How should we handle some of the more exotic tools and needs?
- How can we best support tools like Orca that provide two different functions?
We agreed that once we establish the options that should be offered we would need to come up with a set of standard hot-keys for each of those options for users who cannot access the dialog directly.
Anyway, there is a lot more to think about and discuss. An earlier version of this proposal was attached to Bug #526070.
We will be discussing this again an the GNOME Accessibility meeting in #a11y on GimpNet at 9:30AM EST (13:30 UTC) today (Monday).
What do you think?
[1] http://library.gnome.org/users/gnome-access-guide/2.22/enabling-accessibility.html.en
[2] If you don’t buy that people think their computer is broken, check out the anger here: http://en.wikipedia.org/wiki/Talk:Sticky_keys
