GNOME.org
 

Re: [gdm-list] Bringing back a11y

Hello Brian,


Thanks for your reply and the clear listing of the different points.

(Sorry for the little mess in my previous message; in fact, I forgot
to delete the draft-part above the quote before sending the email.)


At 1:48 PM -0600 2/7/08, Brian Cameron wrote:

Francesco:


Your question is about the transfer of the AT starting mechanism from
the gdm 2.20 to the new branch.

I would like to use the opportunity to look at the problem from
another point of view:


Thanks for bringing this up.  I definitely agree that we should
think about this, and design a better solution for users who need
to launch AT programs.

Let's take a step back and review the requirements:

- We need the ability to launch AT programs via gestures
  (key-combinations, mouse button presses, and dwell activities).
  This is because some users, such as people who are blind
  or who can only use a switch-button, need some mechanism
  to launch AT programs in order to interact with the GUI at
  all.


I agree and this is the reason for keeping the fonctionalities
that were provided by the listeners in GDM 2.20.



- Commands that get launched need to be configurable since
  users may need to launch AT programs with special options
  or use an AT program that might not be integrated into GDM
  by default.


Indeed, for example in the case of an accessibility menu, the same
program could be listed several times (with varying names) for
different configurations.



- All functionality in the GUI needs to be keyboard navigable


I supposed that in the meantime this would be obvious for any
program that would like to call itself "modern" or uptodate.
(I suppose that the new GDM will be fully navigable by keyboard.)

And vice-versa: any command available somewhere in the program
should also be available in the menus of the program.



- We need some mechanism to switch to an a11y theme.  To
  support multi-user systems, it would be ideal to allow users
  to be able to switch to the a11y themes via a hotkey or
  dwell gesture.


Or via a theme menu. But I agree: the hotkeys or dwell gestures
are needed for users that have difficulties to decipher the
default theme.




Note that the GNOME desktop session has similar problems.  There
is no way to launch AT programs on-demand in your GNOME session.

A person with a11y needs would require that someone configure
their system to autolaunch the tools that they need via GConf
settings.

It would be ideal if there were a common solution to solve this
problem for both GDM and the GNOME desktop session.  Now that GDM
2.21 is using metacity, perhaps the best long-term solution
would be to simply improve metacity so users can define hotkey,
button-press and dwell gestures to launch AT programs (or other
programs) on-demand.  Then this functionality could just be used
in both GDM and for the user desktop session.


Maybe a standard should be created about how to launch the different
Assistive Technologies. Or does such a standard already exist?




My first question: Why not make the presence of Assistive Technology
visible in the greeter for example by providing an Accessibility
menu that contains menuitems for the different ATs offered at login
time.


I think such a feature would be very helpful.  It would help users
who are able to navigate the UI to launch AT programs that they
need.

Ideally, such a solution should be configurable.  Users may need
to launch AT programs with different arguments or may need to
launch AT programs that are not integrated into GDM.  So, if a
menu or pop-up dialog is shown, users should be able to add new
programs to the list of choices via configuration.

This is not strictly a requirement if users can also launch AT
programs via hotkey and dwell gestures, but it would definitely
improve usability for users who are able to navigate the UI
without first needing to launch an AT program.


Indeed; I agree.




The listener can then use gdk_screen_get_toplevel_windows to get a
list of windows running in the session, iterate over them, use the
GDK_WINDOW_XWINDOW () macro on the resulting gdk windows to get their
corresponding XIDs and use  XGetProperty to find the window with the
_NET_WM_NAME set to "Login Window" or WM_WINDOW_ROLE set to
"greeter-login-window".


And if instead of using the system of window border crossing,
some software capable of recognising mouse gestures independently from
the window that is on the screen? (For example similar to some gesture
recognition offered by addons in browsers?)


I agree.  The existing dwellmouselistener only supports recognizing
events based on window border crossings.  While this meets the
requirements of a dwell gesture, there are probably better types of
dwell gestures that could be supported.

There probably should be a usability study to determine what gestures
are required and most usable for launching various types of AT programs.

Whatever types of dwell gestures we decide to support should likewise
be configurable so that users can specify what programs should be
launched when gestures are received.


It was not accessibility related, but I saw a mouse gesture software
(on a commercial platform), where the user could define the gesture
and the action triggered by the gesture. Among the actions there was
launching/quitting applications/scripts, sending shortcuts/keystrokes,
select menu items,...

Unfortunately, as far as I know, there is not a reliable mouse gestures
application for GNOME yet.




Another point that might also deserve some attention is the passing of
the activated ATs to the following gnome session and similar on logout.
I think that the following bug addressed the issue:
http://bugzilla.gnome.org/show_bug.cgi?id=411501


This is a good idea, but there are some difficulties that make this
a challange:

+ The needs of navigating the login screen is fairly trivial, compared
  with the needs of navigating your GNOME session.  So you might want
  to launch AT programs differently at login time to reflect this.

+ Also, on multi-user systems the AT programs may be shared by multiple
  users with different needs.  For example, it might make the most sense
  to launch GOK in "dwell" mode rather than "click" mode at login time,
  since this is more usable for a wider audience.  However, some users
  might really want "click" mode in their actual GNOME session.

So, it probably does not make sense to pass the actual command that
GDM uses to the GNOME session.

In the above bug report, it was decided that the best way to deal
with this could be to pass a label such as "text-to-speech" or
"on-screen-keyboard" to the session.  This way the user could
configure what "text-to-speech" means differently in the GNOME
session versus at login time.


What about an option on the greeter (or a11y theme) that gives the user
the choice. This could even be fine tuned:
- enable ATs in GNOME session only if the corresponding AT is not set to
automatically start
- override AT settings of GNOME session
(This are only quick examples with no serious reflection.)




As I don't have a good overview of the different Assistive Technologies,
I am also sending a copy of this message to the gnome-accessibility-list in
the hope that people with more knowledge will add their contribution.
(I think that the best is to send all answers to the gdm list where the
discussion started.)


As I suggested, I think the best long-term solution would be to find
a way to support keybindings and dwell gestures to launch AT programs
that works both in the GNOME session and at login time.


In other words, we need standards!?



However, in the meanwhile, it might make the most sense to continue
supporting something similar to keymouselistener and dwellmouselistener.
These are fairly trivial to port to the new GDM 2.21 and would be
immediately useful.  Any other design would likely take some release
cycles to design and complete.


Yes, the users should get back at least what they had before. If
moreover, there was the possibility to add additional ways to
access the different ATs, that would be a plus. The new ways should
not imply the removal of the old ways of launching ATs; both should
coexists, at least until the new ways have become a
"quasi"-standard.


Regards.

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