[gdm-list] Information about a11y requirements for the new GDM rewrite






Overview of a11y
================

In GDM 2.20, accessibility is turned off by default.  It might be okay
to turn it on by default, but I think some users would want the ability
to turn this off.  Reasons include:

- Most users don't need a11y features.
- There is some performance and security impact to running with a11y
  turned on.
- Starting at-spi-registryd opens another avenue that can be used for
  snooping on running programs.  For example, at-spi-registryd uses
  ORBit2 and users should probably make sure they don't have ORBit2
  configured to allow remote machines to connect over TCP/IP.  Otherwise
  people on remote machines might be able to remotely connect to the
  at-spi-registryd and snoop on the running login program.
- Most AT programs haven't been audited for use with the login program
  so some users might not be comfortable using them, especially if they
  don't need them.

Note that AT programs do not work with custom widgets unless those
custom widgets have been written with AT support.  I am not sure if we
are using any custom widgetry in the new GDM.  If so, some work might
be needed to get these widgets working with orca, GOK, etc.

Another a11y issue is that blind users need to be able to navigate to
all functionality via keyboard navigation.  This has nothing to do with
at-spi-registryd or the AT programs.  I am not sure how the new GDM
will handle allowing the user to switch focus between different
programs (e.g. gnome-power-manager).  Perhaps we get this for free
by using metacity and Ctrl-Alt-Tab?

Launching AT programs
=====================

The starting of at-spi-registryd is part of the solution for
starting AT programs.  This daemon must be started by GDM for programs
like orca and GOK to work, but GDM needs some mechanism to start these
AT programs (or others like onscreen).

There has been some discussion that it might be handy to add a menu or
something that can be used to launch AT programs like GOK and orca.
This would be useful for users with some types of disabilities, such
as users who want to run GOK so they have an on-screen keyboard.  Such
users can probably navigate a menu without further assistance.

However, blind users obviously can't navigate such menus until after
orca is launched.  It is not really desirable to always run orca
since most users don't want the login program to talk to them by
default in text-to-speech mode.  Also, in multi-user environments,
it might make sense for some users to need these features and other
users to not need them.

To support this ability, GDM 2.20 has gesture listeners.  This
framework uses GTK_MODULES that listen for certain gesture events
and launch the AT programs when the gesture has been received.  So
when a11y is turned on, GDM starts GUI's with the --gtk-module argument
passing it the following value (as defined in the GDM configuration):

gail:atk-bridge:@libdir@/gtk-2.0/modules/libdwellmouselistener:@
libdir@/gtk-2.0/modules/libkeymouselistener

The libdwellmouselistener and libkeymouselistener modules provides some
basic gestures that can be performed with the normal keyboard and mouse.
It is necessary to start the GUI with gail and atk-bridge for
the program to be accessible in general.  Without starting GUI's
with gail and atk-bridge, the programs won't connect to the
at-spi-registryd daemon.  In a normal desktop session this is
taken care of for you by gnome-session, but GDM has to start gail and
atk-bridge by hand since gnome-session obviously isn't running.

These modules use the AccessDwellMouseEvents and AccessKeyMouseEvents
configuration files to specify what gestures are supported and what
AT programs are launched.  It is desirable for users to be able to
configure the gestures because the default gestures might be difficult
for users with certain disabilities to perform.  Therefore, users can
configure the gestures so that they are most comfortable to perform
for whatever disability they have.

The original reason for writing these as GTK modules was so that people
could write their own gesture listener modules if they have
special needs.  Perhaps, for example, some users might have special
hardware and would want to be able to launch programs when they
perform a gesture that their hardware supports.  The GTK_MODULE
approach makes it easy for people to figure out how to add their
own.  So it is desirable for users to be able to configure the
list of modules that GDM will use when starting GUI's.

You can look at these gesture listener configuration files in GDM
2.20 to see what the appropriate commands are for launching orca and GOK
at login time.  Note that these commands take special options to ensure
they work properly with GDM.  For example, GOK supports a --login option
and orca takes options so you can control whether it starts up with
magnifier or text-to-speech mode.

The reason that the gesture listeners have separate configuration files
is that it is possible to use these gesture listeners with other
programs outside of GDM.  You can obviously use them with any GTK+
program if you want.

For reference, these modules were written by myself, Niall Power,
and Bill Haneman, all from Sun.  Minor patches to the code has been
provided over the past years to fix various bugs, but nothing
significant.

What needs to be done
=====================

Probably the easiest thing would be to do the following:

- Port the 2.20 gesture listeners and their configuration files to SVN
  head.
- Fix GDM so it launches the simple-greeter (and any other GUI's)
  with the --gtk-modules argument.
- Make it possible for users to configure whether a11y is turned
  on or off and what modules to launch with the GUI's.
- Some ability to switch to a11y GTK+ themes.  This should be done
  via hotkey since users with vision impairments can't necessarily
  interact with any GUI elements.
- Optionally add a menu so that users can launch AT programs
  without needing to perform a gesture.  This would require some
  configuration, I'd think, to specify what AT programs to launch
  and whether the menu should be available or not.

Or, we could come up with some new way to support all this functionality
I suppose.  For example, it might make sense to instead integrate a
magnifier and on-screen keyboard directly into the GDM GUI.

For example, you could implement a magnifier by having hotkeys that
increase/decrease font size, and an on-screen keyboard could be made
available by having an option which shows a grid of letters and lets
you type letters by clicking or dwelling the mouse over them.

Brian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]