Re: [g-a-devel] [gdm-list] What's the Status of Audio in GDM?
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Matthias Clasen <mclasen redhat com>
- Cc: For testers of Fedora Core development releases <fedora-test-list redhat com>, GNOME Accessiblity Developers Mailing List <gnome-accessibility-devel gnome org>, gdm-list gnome org, gkraft gnome org
- Subject: Re: [g-a-devel] [gdm-list] What's the Status of Audio in GDM?
- Date: Mon, 05 May 2008 15:21:36 -0500
Matthias:
Perhaps someone could start a wiki at http://live.gnome.org/GAP/gestures
and create three columns of what to start which which gestures. For
example:
=================================================
Action GNOME GDM* KDE
=================================================
gnome-at-visual
gnome-at-mobility
I'd suggest that there are 3 types of users with mobility needs:
1) Users who can move the mouse cursor and click a button
2) Users who can move the mouse cursor and can not click a button
(e.g. GOK in "dwell mode")
3) Users who can only click a button.
Users in case #1 can function in dwell mode, so you can support both
case #1 and #2 by making GOK launch in dwell mode. However, users
in case #3 require that GOK is launched in button-press mode.
While dasher is a great program, it really only works in case #1, so
GOK in "dwell" mode is probably a better default on-screen-keyboard
since it supports a wider user base.
So there probably needs to be 2 or 3 actions that correspond to
gnome-at-mobility depending on whether you want to support case #1
and #2 separately or just only support dwell mode.
-------------------------------------------------
*global settings for user GDM.
While discussing this, let me reiterate that I find this abstract
classification (visual/mobility) entirely unhelpful.
Assume the old gdm supported three shortcuts, say C-M for magnifier, C-S
for screenreader and C-K for onscreen keyboard, which of the two get
mapped to visual+mobility, and which tool looses out ?
The "Preferred Applications" configuration capplet allows distros to
specify which program is the default program for screenreader and
on-screen keyboard. I'd anticipate that the action should just launch
whichever program is specified.
Distros should probably set the default to the program which works for
the widest set of users. It would probably be good to enhance the
"Preferred Applications" to provide separate choices for on-screen
keyboard for the 3 typical use cases, and to be able to specify which of
the 3 use cases the user falls into.
Keybindings, such as <ctrl>-S or <ctrl>-M are useful for users with
visual issues. Most blind users, for example, would want to use the
keyboard to launch AT programs. Blind users would have difficulty
using the mouse, so mouse-based gestures are not be so useful.
To support users with mobility issues. For example, users who are
paralyzed and can only move the cursor via head-tracking hardware
need to be able to launch programs using mouse cursor gestures.
For example, perhaps moving the mouse cursor to the top edge of
the screen and leaving it there for 2 seconds, then moving it
to the bottom edge and leaving it there for 2 seconds would launch
GOK in dwell mode. Users with mobility issues tend to have difficulty
using the keyboard, so keybindings are not so useful.
In other words, you need a solution for launching AT programs both
via the keyboard and also via mouse gestures. keybindings map to
"at-visual" and mouse cursor gestures map to "at-mobility".
There are other cases that aren't supported by the above two cases (such
as a user who is both blind and paralyzed). However, the above two use
cases are a good starting point and meet the needs of most users with
a11y needs. Over time, we would hopefully come up with solutions to
make the desktop usable for users who have other types of needs.
In saying this, I just want to highlight that it is useful to keep in
mind that the idea of supporting "gestures" should ideally be extensible
so that new types of "gestures" could be plugged into a framework.
Since g-s-d supports a plugin framework, it should be possible to write
additional plugin modules to support other kinds of gestures (perhaps
hardware specific) for launching AT programs as needed.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]