Carrying over ATs from GDM to GNOME session (brainstorm)

[Francesco Fumanti]

Hi,



I have been asked to start a brainstorm thread about how the assistive
tools that a user has activated in GDM can automatically be started in
the GNOME session.

As I suppose that it will probably be the gnome-settings-daemon that
will be responsible for the carrying over of the ATs activated in GDM
and I only know little about how it works, this email will mainly
concentrate on the point of view of the user. I hope that other people
will take the opportunity to add their own view about the problem to
this thread, regardless of whether it is a technical view or not.



The first question that comes to my mind: can the carrying over be
always active because GDM is by itself able to determine when to carry
over the ATs, or is an option necessary for the user to activate the
carrying over?

Let's start with the case where there is an option for the user to
activate the carrying over, as it is the more simple case:

On obvious location for the option would be the accessibility dialog of
GDM. This will however have the consequence that there will only be one
option for all the users. It might be better giving each user an own
option; the option could for example only appear after the user has
entered his login name and before he enters the password. In this case,
the accessibility dialog is not anymore a good location for the carry
over option; it might be better to make it appear under the password
entry field; and it only needs to appear when the user has activated one
or more assistive tools.



Next question: What should happen if the user activates the carry over
option and there already are other tools to automatically start in the
GNOME session? For two different onscreen keyboards, that should not be
a problem if they are started simultaneously in the GNOME session; but
what about two different screen readers?

A good solution to this problem might make the carry over option useless
if GDM is able to determine by itself what tool to carry over.


Let's consider the case where there is the carry over option and it is
specific to each user. I can imagine that the user activates it at least
the first time he uses the GNOME session; if he uses different assistive
tools in the GNOME session than in GDM, he will probably not activate it
in the following GNOME sessions as I assume that he has configured his
GNOME session to automatically start the assistive tools that he wants.


Is there anybody with ideas about a reliable way to automatically
determine what assistive tools to carry over by taking into account the
assistive tools configured to automatically start in the GNOME session?
Is there anybody with a slightly different or even a completely
different approach to the whole problem? Please step in and inform us
about it; it is the purpose of this thread.


Cheers,

Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

Yeah!  Thanks for starting this, Franceso.  It is highly needed feature
to improve the out-of-the-box experience for GNOME.  If this can be
achieved, and we can convince distros to turn a11y on for gdm by
default, we can provide an experience that eliminates the need for the
user to login, enable a11y, logout, and login again.

> and I only know little about how it works, this email will mainly
> concentrate on the point of view of the user. I hope that other people
> will take the opportunity to add their own view about the problem to
> this thread, regardless of whether it is a technical view or not.

Coming at it from the user point of view first is the right way to
approach this, IMO.

Your discussion below seems to be able to be boiled down to the
question of providing some level of reasonable access to the login
screen using some assistive technologies, but then allowing different
assistive technologies (or perhaps just different settings for the same
assistive technologies) to be used in the user session.  There's also
the notion of carrying over settings such as theming (for high contrast
large print, etc.) and AccessX preferences for StickyKeys, MouseKeys,
etc.

So...just thinking out loud...the two main use cases seem to be 1) the
initial login of a user, and 2) logins from the same user thereafter.

For the initial login, I'd guess we'd want to automatically carry over
whatever a11y settings/tools were used at the login screen.  As an
aside -- I believe GDM already saves these settings in its profile so
you do not need to re-enable the assistive technologies when returning
to the GDM screen.  This may or may not be a desirable feature.  I'd
say it's desirable in personal use systems, but perhaps not so
desirable in shared systems.  But, the good thing is that GDM at least
knows what settings need to be retained.

In any case, the user has now logged in for the first time and their
a11y environment is now identical to what they used on the gdm login
screen.  For many settings, the user can customize things further and
the user can also configure any AT's to automatically start when they
log in.

Now assume the user logs out and gets through the login again.  We have
two use cases for that: 1) the user logged in using the same a11y
features as they did before, and 2) the user logged in user different
a11y features.  This is where things can get a bit crazy because either
case may end up conflicting with the preferences the user may have set
for their session.

So...I kind of like your 'carry over' checkbox idea.  If checked, the
user's a11y environment will be reset somehow with the settings used
for logging in.  This would help handle the first login of a user.  If
not checked, nothing will be carried over from the login screen.  This
would help handle the subsequent logins of a user (who has presumably
configured their a11y preferences for their desktop).

I think we might want to uncheck the checkbox by default.  If we could
detect that a user is logging in for the first time or if they modified
the a11y preferences on the login screen, perhaps we could enable the
checkbox by default.

Anyway, that's just me thinking out loud.  Many thanks for starting
this discussion.

Will

> The first question that comes to my mind: can the carrying over be
> always active because GDM is by itself able to determine when to carry
> over the ATs, or is an option necessary for the user to activate the
> carrying over?
>
> Let's start with the case where there is an option for the user to
> activate the carrying over, as it is the more simple case:
>
> On obvious location for the option would be the accessibility dialog of
> GDM. This will however have the consequence that there will only be
> one option for all the users. It might be better giving each user an
> own option; the option could for example only appear after the user
> has entered his login name and before he enters the password. In this
> case, the accessibility dialog is not anymore a good location for the
> carry over option; it might be better to make it appear under the
> password entry field; and it only needs to appear when the user has
> activated one or more assistive tools.
>
>
>
> Next question: What should happen if the user activates the carry over
> option and there already are other tools to automatically start in the
> GNOME session? For two different onscreen keyboards, that should not
> be a problem if they are started simultaneously in the GNOME session;
> but what about two different screen readers?
>
> A good solution to this problem might make the carry over option
> useless if GDM is able to determine by itself what tool to carry over.
>
>
> Let's consider the case where there is the carry over option and it is
> specific to each user. I can imagine that the user activates it at
> least the first time he uses the GNOME session; if he uses different
> assistive tools in the GNOME session than in GDM, he will probably not
> activate it in the following GNOME sessions as I assume that he has
> configured his GNOME session to automatically start the assistive
> tools that he wants.
>
>
> Is there anybody with ideas about a reliable way to automatically
> determine what assistive tools to carry over by taking into account
> the assistive tools configured to automatically start in the GNOME
> session? Is there anybody with a slightly different or even a
> completely different approach to the whole problem? Please step in and
> inform us about it; it is the purpose of this thread.
>
>
> Cheers,
>
> Francesco

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Brian Cameron]

Willie/Francesco:

> Yeah!  Thanks for starting this, Franceso.  It is highly needed feature
> to improve the out-of-the-box experience for GNOME.  If this can be
> achieved, and we can convince distros to turn a11y on for gdm by
> default, we can provide an experience that eliminates the need for the
> user to login, enable a11y, logout, and login again.

Personally, I think that a more serious problem is fixing
gnome-settings-daemon and control-center to allow AT programs to be
easily launched via hotkey and gestures.  Refer here:

   https://bugzilla.gnome.org/show_bug.cgi?id=531595
   https://bugzilla.gnome.org/show_bug.cgi?id=531596

The ability to "carry-over" AT programs from the login screen to the
user session is not such a needed feature if the user can easily launch
the AT programs once their session starts.  But, for this to work, we
need both keybinding and mouse-gesture mechanisms for launching the
needed AT programs.  As stated in the bug report, it would make the
most sense if this framework worked in both GDM and the user session.
This way the same mechanism for launching AT programs in GDM works
for the user session as well.

Typically users only need to do this sort of boot-strapping on
first-login anyway, since users would typically would configure AT
programs to always launch in their user session on login.  So, after
first login, I am not sure the need to "carry over" AT settings even
makes sense.  Willie also seemed to express concern about this.

It would be nice to eliminate some of the bootstrapping by having AT
programs "carry over" to the user session.  However, many users will
configure the AT programs to meet their own individual needs.  For
example, some users may wish to use onscreen instead of GOK, or vice
versa.  Dealing with the complexities of making AT programs "carry over"
while honoring the users personal preferences seems hard to implement
correctly.

Remember that the login screen has a very simple GUI.  Typically users
only need to be able to enter their username and password.  So, the
default AT program that gets launched for the login screen may be
sufficient to navigate this screen, but may not be really configured
for the user to navigate their full desktop.  In other words, there is
no real guarantee that the AT program (or how they are configured to
work at login time) makes sense for the normal user session.  This
also complicates things, I think.

Note that this topic was discussed before, in 2007.  A patch for the
old GDM was written that implemented the feature you are describing.

   https://bugzilla.gnome.org/show_bug.cgi?id=411501

However, as you can see from the bug comments, the patch was never
really finished, and some of the design issues were never resolved.
It would probably be good to look over that previous work to see
what was done before, and to check if any of the ideas might be
useful in this effort.

Brian
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Ian Pascoe]

Can we please clarify how we believe things work at the moment - just so as
we all know where we're starting from.

Ian

-----Original Message-----
From: gnome-accessibility-list-bounces@...
[mailto:gnome-accessibility-list-bounces@...]On Behalf Of Brian
Cameron
Sent: 03 November 2009 17:00
To: Willie Walker
Cc: Jon McCann; gnome-accessibility-list@...
Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm)



Willie/Francesco:

> Yeah!  Thanks for starting this, Franceso.  It is highly needed feature
> to improve the out-of-the-box experience for GNOME.  If this can be
> achieved, and we can convince distros to turn a11y on for gdm by
> default, we can provide an experience that eliminates the need for the
> user to login, enable a11y, logout, and login again.

Personally, I think that a more serious problem is fixing
gnome-settings-daemon and control-center to allow AT programs to be
easily launched via hotkey and gestures.  Refer here:

   https://bugzilla.gnome.org/show_bug.cgi?id=531595
   https://bugzilla.gnome.org/show_bug.cgi?id=531596

The ability to "carry-over" AT programs from the login screen to the
user session is not such a needed feature if the user can easily launch
the AT programs once their session starts.  But, for this to work, we
need both keybinding and mouse-gesture mechanisms for launching the
needed AT programs.  As stated in the bug report, it would make the
most sense if this framework worked in both GDM and the user session.
This way the same mechanism for launching AT programs in GDM works
for the user session as well.

Typically users only need to do this sort of boot-strapping on
first-login anyway, since users would typically would configure AT
programs to always launch in their user session on login.  So, after
first login, I am not sure the need to "carry over" AT settings even
makes sense.  Willie also seemed to express concern about this.

It would be nice to eliminate some of the bootstrapping by having AT
programs "carry over" to the user session.  However, many users will
configure the AT programs to meet their own individual needs.  For
example, some users may wish to use onscreen instead of GOK, or vice
versa.  Dealing with the complexities of making AT programs "carry over"
while honoring the users personal preferences seems hard to implement
correctly.

Remember that the login screen has a very simple GUI.  Typically users
only need to be able to enter their username and password.  So, the
default AT program that gets launched for the login screen may be
sufficient to navigate this screen, but may not be really configured
for the user to navigate their full desktop.  In other words, there is
no real guarantee that the AT program (or how they are configured to
work at login time) makes sense for the normal user session.  This
also complicates things, I think.

Note that this topic was discussed before, in 2007.  A patch for the
old GDM was written that implemented the feature you are describing.

   https://bugzilla.gnome.org/show_bug.cgi?id=411501

However, as you can see from the bug comments, the patch was never
really finished, and some of the design issues were never resolved.
It would probably be good to look over that previous work to see
what was done before, and to check if any of the ideas might be
useful in this effort.

Brian
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Brian Cameron]

Ian:

> Can we please clarify how we believe things work at the moment - just so as
> we all know where we're starting from.

GDM 2.20 and earlier versions supported a "gesture listener" mechanism
so that users could launch AT programs on the fly via keybindings or
mouse dwell gestures.  This was dropped in GDM 2.21 or later, when the
GDM code was rewritten.  With the new GDM, users need to navigate the
a11y menu to enable AT programs, or modify their GDM configuration to
specify that AT programs should always be launched.

However, this is a problem for some users with disabilities since there
is a chicken and egg problem.  Users may not be able to navigate through
the a11y dialog without AT programs already running.  Blind users, for
example, would need orca running to be able to navigate the GUI at all
(unless it is very simple to do via keynav without feedback, but
unfortunately the new GDM's a11y dialog is not accessible via keynav at
all currently).  Ideally it should be possible for users with
disabilities to enable needed a11y features without needing someone else
to help them set up their system.

The reason the "gesture listeners" feature was dropped was because it
was decided that this feature should not be GDM specific.  Now that the
new GDM uses the desktop infrastructure (gnome-settings-daemon,
metacity, gnome-session, etc.), it would be better if there were a
single infrastructure for launching AT programs via hotkey or mouse
dwell gesture that worked in both GDM and the user session.  So, it
seems to make sense for gnome-settings-daemon to manage this for either
GDM or the user session.  The two bugs I referenced in my previous email
are about this.

Neither the old or new GDM "carried over" any AT programs to the user
session.  So, using either the old or new GDM, users need to separately
setup their user session with any AT programs needed.  Some users feel
that it would be useful if the a11y settings did "carry over", but there
are issues (like the ones Willie and I highlighted about the fact that
users may want different AT preferences for login versus normal user
session navigation).

That said, I think the ability to launch programs in either GDM or the
user session via hotkey/dwell gestures is a more serious problem that
needs solving.

Brian

> -----Original Message-----
> From: gnome-accessibility-list-bounces@...
> [mailto:gnome-accessibility-list-bounces@...]On Behalf Of Brian
> Cameron
> Sent: 03 November 2009 17:00
> To: Willie Walker
> Cc: Jon McCann; gnome-accessibility-list@...
> Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm)
>
>
>
> Willie/Francesco:
>
>> Yeah!  Thanks for starting this, Franceso.  It is highly needed feature
>> to improve the out-of-the-box experience for GNOME.  If this can be
>> achieved, and we can convince distros to turn a11y on for gdm by
>> default, we can provide an experience that eliminates the need for the
>> user to login, enable a11y, logout, and login again.
>
> Personally, I think that a more serious problem is fixing
> gnome-settings-daemon and control-center to allow AT programs to be
> easily launched via hotkey and gestures.  Refer here:
>
>    https://bugzilla.gnome.org/show_bug.cgi?id=531595
>    https://bugzilla.gnome.org/show_bug.cgi?id=531596
>
> The ability to "carry-over" AT programs from the login screen to the
> user session is not such a needed feature if the user can easily launch
> the AT programs once their session starts.  But, for this to work, we
> need both keybinding and mouse-gesture mechanisms for launching the
> needed AT programs.  As stated in the bug report, it would make the
> most sense if this framework worked in both GDM and the user session.
> This way the same mechanism for launching AT programs in GDM works
> for the user session as well.
>
> Typically users only need to do this sort of boot-strapping on
> first-login anyway, since users would typically would configure AT
> programs to always launch in their user session on login.  So, after
> first login, I am not sure the need to "carry over" AT settings even
> makes sense.  Willie also seemed to express concern about this.
>
> It would be nice to eliminate some of the bootstrapping by having AT
> programs "carry over" to the user session.  However, many users will
> configure the AT programs to meet their own individual needs.  For
> example, some users may wish to use onscreen instead of GOK, or vice
> versa.  Dealing with the complexities of making AT programs "carry over"
> while honoring the users personal preferences seems hard to implement
> correctly.
>
> Remember that the login screen has a very simple GUI.  Typically users
> only need to be able to enter their username and password.  So, the
> default AT program that gets launched for the login screen may be
> sufficient to navigate this screen, but may not be really configured
> for the user to navigate their full desktop.  In other words, there is
> no real guarantee that the AT program (or how they are configured to
> work at login time) makes sense for the normal user session.  This
> also complicates things, I think.
>
> Note that this topic was discussed before, in 2007.  A patch for the
> old GDM was written that implemented the feature you are describing.
>
>    https://bugzilla.gnome.org/show_bug.cgi?id=411501
>
> However, as you can see from the bug comments, the patch was never
> really finished, and some of the design issues were never resolved.
> It would probably be good to look over that previous work to see
> what was done before, and to check if any of the ideas might be
> useful in this effort.
>
> Brian
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Ian Pascoe]

Brian

Thanks, that's great for the log in.  What currently happens on the log out
and return to GDM - does the AT, if activated at log in re-enliven, or does
it return to the GDM default state?

I presume that if AT is launched by GDM, the ATs are killed before the
desktop is launched thereby avoiding possible multiple instances of ATs in
the desktop session?

Ian

-----Original Message-----
From: Brian.Cameron@... [mailto:Brian.Cameron@...]
Sent: 03 November 2009 21:07
To: ianpascoe@...
Cc: gnome-accessibility-list@...
Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm)



Ian:

> Can we please clarify how we believe things work at the moment - just so
as
> we all know where we're starting from.

GDM 2.20 and earlier versions supported a "gesture listener" mechanism
so that users could launch AT programs on the fly via keybindings or
mouse dwell gestures.  This was dropped in GDM 2.21 or later, when the
GDM code was rewritten.  With the new GDM, users need to navigate the
a11y menu to enable AT programs, or modify their GDM configuration to
specify that AT programs should always be launched.

However, this is a problem for some users with disabilities since there
is a chicken and egg problem.  Users may not be able to navigate through
the a11y dialog without AT programs already running.  Blind users, for
example, would need orca running to be able to navigate the GUI at all
(unless it is very simple to do via keynav without feedback, but
unfortunately the new GDM's a11y dialog is not accessible via keynav at
all currently).  Ideally it should be possible for users with
disabilities to enable needed a11y features without needing someone else
to help them set up their system.

The reason the "gesture listeners" feature was dropped was because it
was decided that this feature should not be GDM specific.  Now that the
new GDM uses the desktop infrastructure (gnome-settings-daemon,
metacity, gnome-session, etc.), it would be better if there were a
single infrastructure for launching AT programs via hotkey or mouse
dwell gesture that worked in both GDM and the user session.  So, it
seems to make sense for gnome-settings-daemon to manage this for either
GDM or the user session.  The two bugs I referenced in my previous email
are about this.

Neither the old or new GDM "carried over" any AT programs to the user
session.  So, using either the old or new GDM, users need to separately
setup their user session with any AT programs needed.  Some users feel
that it would be useful if the a11y settings did "carry over", but there
are issues (like the ones Willie and I highlighted about the fact that
users may want different AT preferences for login versus normal user
session navigation).

That said, I think the ability to launch programs in either GDM or the
user session via hotkey/dwell gestures is a more serious problem that
needs solving.

Brian

> -----Original Message-----
> From: gnome-accessibility-list-bounces@...
> [mailto:gnome-accessibility-list-bounces@...]On Behalf Of Brian
> Cameron
> Sent: 03 November 2009 17:00
> To: Willie Walker
> Cc: Jon McCann; gnome-accessibility-list@...
> Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm)
>
>
>
> Willie/Francesco:
>
>> Yeah!  Thanks for starting this, Franceso.  It is highly needed feature
>> to improve the out-of-the-box experience for GNOME.  If this can be
>> achieved, and we can convince distros to turn a11y on for gdm by
>> default, we can provide an experience that eliminates the need for the
>> user to login, enable a11y, logout, and login again.
>
> Personally, I think that a more serious problem is fixing
> gnome-settings-daemon and control-center to allow AT programs to be
> easily launched via hotkey and gestures.  Refer here:
>
>    https://bugzilla.gnome.org/show_bug.cgi?id=531595
>    https://bugzilla.gnome.org/show_bug.cgi?id=531596
>
> The ability to "carry-over" AT programs from the login screen to the
> user session is not such a needed feature if the user can easily launch
> the AT programs once their session starts.  But, for this to work, we
> need both keybinding and mouse-gesture mechanisms for launching the
> needed AT programs.  As stated in the bug report, it would make the
> most sense if this framework worked in both GDM and the user session.
> This way the same mechanism for launching AT programs in GDM works
> for the user session as well.
>
> Typically users only need to do this sort of boot-strapping on
> first-login anyway, since users would typically would configure AT
> programs to always launch in their user session on login.  So, after
> first login, I am not sure the need to "carry over" AT settings even
> makes sense.  Willie also seemed to express concern about this.
>
> It would be nice to eliminate some of the bootstrapping by having AT
> programs "carry over" to the user session.  However, many users will
> configure the AT programs to meet their own individual needs.  For
> example, some users may wish to use onscreen instead of GOK, or vice
> versa.  Dealing with the complexities of making AT programs "carry over"
> while honoring the users personal preferences seems hard to implement
> correctly.
>
> Remember that the login screen has a very simple GUI.  Typically users
> only need to be able to enter their username and password.  So, the
> default AT program that gets launched for the login screen may be
> sufficient to navigate this screen, but may not be really configured
> for the user to navigate their full desktop.  In other words, there is
> no real guarantee that the AT program (or how they are configured to
> work at login time) makes sense for the normal user session.  This
> also complicates things, I think.
>
> Note that this topic was discussed before, in 2007.  A patch for the
> old GDM was written that implemented the feature you are describing.
>
>    https://bugzilla.gnome.org/show_bug.cgi?id=411501
>
> However, as you can see from the bug comments, the patch was never
> really finished, and some of the design issues were never resolved.
> It would probably be good to look over that previous work to see
> what was done before, and to check if any of the ideas might be
> useful in this effort.
>
> Brian
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

> Personally, I think that a more serious problem is fixing
> gnome-settings-daemon and control-center to allow AT programs to be
> easily launched via hotkey and gestures.  Refer here:
>
>   https://bugzilla.gnome.org/show_bug.cgi?id=531595
>   https://bugzilla.gnome.org/show_bug.cgi?id=531596

This regression is indeed bad.  It's fortunate that the bugs are logged,
however (and thank you!), and the discussion of this thread can continue
to focus on carrying over ATs from GDM to GNOME session.

> The ability to "carry-over" AT programs from the login screen to the
> user session is not such a needed feature if the user can easily launch
> the AT programs once their session starts.

An issue which the carry over solution would solve is the very awkward
method by which a11y needs to be enabled for the desktop.  Unlike gdm,
which will have a11y enabled by default, the user session has a11y
disabled by default.  So, if you can get an AT running during an
inaccessible session, you really need to hope that the AT sets the a11y
gconf flag and offers you with the ability to log out.

The carry over would help ensure that the a11y gconf flag is set for the
user if it is needed, making the user session accessible.  Imagine also
that I needed high contrast large print inverse to log in.  It sure
seems awkward to have to go through the theme selection process all over
again once I login.  I think the carry over solution would be a much
more pleasant out of the box experience.

> Typically users only need to do this sort of boot-strapping on
> first-login anyway, since users would typically would configure AT
> programs to always launch in their user session on login.  So, after
> first login, I am not sure the need to "carry over" AT settings even
> makes sense.  Willie also seemed to express concern about this.

If the carry over feature were in place, I believe the most common place
one would want to use gestures to launch an AT would be at the login
screen.  Once a user has logged in, they are likely to configure their
session so the AT automatically starts when they log in.

The cases where I've seen end users wanting to start an AT from a
keystroke is for cases where they really want to restart the AT.  For
example, sometimes the a11y infrastructure hangs or an app hangs or orca
hangs.  The quickest way to unhang the system can be to restart orca
because orca clears up a bunch of stuff when it initializes.  So, the
user can create a custom keystroke to launch Orca via the
System->Preferences->Keyboard_Shortcuts dialog.

However, I might be missing something, which is the case where a
gnome-session is *always* running, such as in a public kiosk.  It seems
to me that the System->Preferences->Keyboard_Shortcuts dialog would
provide at least some way to set up the AT's to launch via keystrokes.
That would then leave the non-keyboard related gestures (e.g., the mouse
enter/leave over boundaries gestures).  I'm not 100% sure, but I think
one of the more useful ones is the dwell gesture provided by
MouseTweaks.  So, that can be resolved by putting the MouseTweaks applet
in the panel and hope/assume that the user has some way of moving the
mouse when they approach one of these public kiosks.

> Dealing with the complexities of making AT programs "carry over"
> while honoring the users personal preferences seems hard to implement
> correctly.

Francesco's solution of offering a checkbox seems like it might work and
be rather simple.

> Note that this topic was discussed before, in 2007.  A patch for the
> old GDM was written that implemented the feature you are describing.
>
>   https://bugzilla.gnome.org/show_bug.cgi?id=411501
>
> However, as you can see from the bug comments, the patch was never
> really finished, and some of the design issues were never resolved.
> It would probably be good to look over that previous work to see
> what was done before, and to check if any of the ideas might be
> useful in this effort.

The work in the bug seems kind of interesting in that the carry over
mechanism is basically an environment variable.  I think a hard part
would be to then turn this into something that makes sure the a11y
settings are set appropriately and as one might expect.  Note also that
if the AT-SPI infrastructure is needed, the gconf key should be set
before any GUI operations are done so that the appropriate a11y modules
can be loaded by GTK+.

I'm curious if some sort of script/app run via an autostart *.desktop
file during the gnome-session initialization phase might be able to
perform some logic based upon the presence/absence (and value if
present) of an environment variable.

Will
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Brian Cameron]

Willie:

>> Personally, I think that a more serious problem is fixing
>> gnome-settings-daemon and control-center to allow AT programs to be
>> easily launched via hotkey and gestures.  Refer here:
>>
>>   https://bugzilla.gnome.org/show_bug.cgi?id=531595
>>   https://bugzilla.gnome.org/show_bug.cgi?id=531596
>
> This regression is indeed bad.  It's fortunate that the bugs are logged,
> however (and thank you!), and the discussion of this thread can continue
> to focus on carrying over ATs from GDM to GNOME session.

I think these issues are related, though.

>> The ability to "carry-over" AT programs from the login screen to the
>> user session is not such a needed feature if the user can easily launch
>> the AT programs once their session starts.
>
> An issue which the carry over solution would solve is the very awkward
> method by which a11y needs to be enabled for the desktop.  Unlike gdm,
> which will have a11y enabled by default, the user session has a11y
> disabled by default.  So, if you can get an AT running during an
> inaccessible session, you really need to hope that the AT sets the a11y
> gconf flag and offers you with the ability to log out.

It makes 100% sense to me for the setting of
/desktop/gnome/interface/accessibility to carry over to the user
session.  If the user launched an AT program in the login program, then
it would make sense for GDM to just go ahead and set this key for the
user session before starting it, for example.

This would be pretty easy to manage.  Things get more tricky when you
want to try and modify the user's configuration so that specific AT
programs launch or themes get specified.  If we want this to happen,
then we need to be careful to never mess up the user's configuration if
they have set their AT preferences to meet their unique needs.

For example, GDM could automatically set the GConf keys associated with
the Preferences->Assistive Technologies "Preferred Applications" window,
So, for example, if the user launches text-to-speech in GDM, then it
might make sense to also set the "Visual" value to "Orca" and check the
Visaul "Run at start" checkbox before starting the session.

But doing this in a way that you are certain to not mess up the user's
personal configuration may be hard.  Perhaps it would be reasonable to
go ahead and set the GConf values for the text-to-speech case only if
the "Run at start" GConf setting is unchecked.  Or to set the user's
theme only if the user is currently using the system default theme.
On first blush, this seems like it could work, but you really need to be
careful when messing around with the user's preferences like this.

> The carry over would help ensure that the a11y gconf flag is set for the
> user if it is needed, making the user session accessible.  Imagine also
> that I needed high contrast large print inverse to log in.  It sure
> seems awkward to have to go through the theme selection process all over
> again once I login.  I think the carry over solution would be a much
> more pleasant out of the box experience.

Right.  Although, providing keybindings and mouse dwell gestures to set
the a11y theme also seems a reasonable solution to avoid this sort of
setup.

>> Typically users only need to do this sort of boot-strapping on
>> first-login anyway, since users would typically would configure AT
>> programs to always launch in their user session on login.  So, after
>> first login, I am not sure the need to "carry over" AT settings even
>> makes sense.  Willie also seemed to express concern about this.
>
> If the carry over feature were in place, I believe the most common place
> one would want to use gestures to launch an AT would be at the login
> screen.  Once a user has logged in, they are likely to configure their
> session so the AT automatically starts when they log in.

Well, it could work one of two ways.

1) The user enters a gesture in GDM.  The values carry over to the user
    session.

2) The user enters a gesture in GDM.  Then after login, the user needs
    to enter the same gesture in the user session.

In both cases, these steps should only be necessary once.  Both GDM and
the user session should remember the settings so that they are used on
subsequent logins.

Obviously solution #1 is nicer.  However, solution #2 is not that much
more cumbersome.  Since, in either case, you need to be able to launch
AT programs via a gesture, it just seems to me that it would make most
sense to enhance the desktop to support launching AT programs via
gestures before solving the problem of carrying over the values from
GDM to the user session.

However, this is a volunteer community, and if volunteers are more
excited to solve problem #2, then there is not any real problem with
addressing that problem first.

> The cases where I've seen end users wanting to start an AT from a
> keystroke is for cases where they really want to restart the AT.  For
> example, sometimes the a11y infrastructure hangs or an app hangs or orca
> hangs.  The quickest way to unhang the system can be to restart orca
> because orca clears up a bunch of stuff when it initializes.  So, the
> user can create a custom keystroke to launch Orca via the
> System->Preferences->Keyboard_Shortcuts dialog.
>
> However, I might be missing something, which is the case where a
> gnome-session is *always* running, such as in a public kiosk.  It seems
> to me that the System->Preferences->Keyboard_Shortcuts dialog would
> provide at least some way to set up the AT's to launch via keystrokes.
> That would then leave the non-keyboard related gestures (e.g., the mouse
> enter/leave over boundaries gestures).

Although the old GDM supported dwell gestures that involved enter/leave
window boundries, this technique probably does not make sense for a more
general solution that also needs to work in the user session.  The old
GDM solution works well for GDM since we know that on startup that
exactly one window is always present.

For a more general solution, a different dwell gesture, like moving the
mouse to a corner of the screen, or wiggling the cursor in a certain
way, probably makes more sense.

> I'm not 100% sure, but I think
> one of the more useful ones is the dwell gesture provided by
> MouseTweaks.  So, that can be resolved by putting the MouseTweaks applet
> in the panel and hope/assume that the user has some way of moving the
> mouse when they approach one of these public kiosks.

If MouseTweaks can solve the problem, that would be awesome.

>> Dealing with the complexities of making AT programs "carry over"
>> while honoring the users personal preferences seems hard to implement
>> correctly.
>
> Francesco's solution of offering a checkbox seems like it might work and
> be rather simple.

I worry this approach would be prone to error.  Users may not realize
they need to set or unset the checkbox - especially if they launched an
AT program via a keybinding rather than the a11y dialog.

It seems better if this could be managed more in an automatic fashion.
This should be possible, though I wonder if additional GConf keys may
be helpful to help keep track of whether GDM should try to modify
the user's configuration or not.

>> Note that this topic was discussed before, in 2007.  A patch for the
>> old GDM was written that implemented the feature you are describing.
>>
>>   https://bugzilla.gnome.org/show_bug.cgi?id=411501
>>
>> However, as you can see from the bug comments, the patch was never
>> really finished, and some of the design issues were never resolved.
>> It would probably be good to look over that previous work to see
>> what was done before, and to check if any of the ideas might be
>> useful in this effort.
>
> The work in the bug seems kind of interesting in that the carry over
> mechanism is basically an environment variable.  I think a hard part
> would be to then turn this into something that makes sure the a11y
> settings are set appropriately and as one might expect.  Note also that
> if the AT-SPI infrastructure is needed, the gconf key should be set
> before any GUI operations are done so that the appropriate a11y modules
> can be loaded by GTK+.
>
> I'm curious if some sort of script/app run via an autostart *.desktop
> file during the gnome-session initialization phase might be able to
> perform some logic based upon the presence/absence (and value if
> present) of an environment variable.

I do not think the environment variable approach is a very good one.  I
just shared that past work for reference.  I think it makes more sense
for GDM to set the user's GConf settings so that things work properly
on login.  The trick is doing this in a way that the user's preferences
never get messed up if the user has actually modified them.

Brian

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

Brian:

>> An issue which the carry over solution would solve is the very awkward
>> method by which a11y needs to be enabled for the desktop.  Unlike gdm,
>> which will have a11y enabled by default, the user session has a11y
>> disabled by default.  So, if you can get an AT running during an
>> inaccessible session, you really need to hope that the AT sets the
>> a11y gconf flag and offers you with the ability to log out.
>
> It makes 100% sense to me for the setting of
> /desktop/gnome/interface/accessibility to carry over to the user
> session.  If the user launched an AT program in the login program, then
> it would make sense for GDM to just go ahead and set this key for the
> user session before starting it, for example.

This would be a big plus.  The existing login/set_a11y/logout/login
process is reasonable, but certainly not compelling.

> But doing this in a way that you are certain to not mess up the user's
> personal configuration may be hard.  Perhaps it would be reasonable to
> go ahead and set the GConf values for the text-to-speech case only if
> the "Run at start" GConf setting is unchecked.  Or to set the user's
> theme only if the user is currently using the system default theme.
> On first blush, this seems like it could work, but you really need to be
> careful when messing around with the user's preferences like this.

Agreed.  We have a mishmash of settings and config files across multiple
areas, so I believe some hardcoding of stuff would probably be necessary
(and perhaps brittle).

>> The carry over would help ensure that the a11y gconf flag is set for
>> the user if it is needed, making the user session accessible.  Imagine
>> also that I needed high contrast large print inverse to log in.  It
>> sure seems awkward to have to go through the theme selection process
>> all over again once I login.  I think the carry over solution would be
>> a much more pleasant out of the box experience.
>
> Right.  Although, providing keybindings and mouse dwell gestures to set
> the a11y theme also seems a reasonable solution to avoid this sort of
> setup.

I'd like to shoot for the star that says "Compelling" on it rather than
"Reasonable".  "Reasonable" usually ends up meaning "the minimal
compromise we make to push a clunky solution."  I think we need to hear
more from our end users about what they think would be compelling.

>> I'm not 100% sure, but I think one of the more useful ones is the
>> dwell gesture provided by MouseTweaks.  So, that can be resolved by
>> putting the MouseTweaks applet in the panel and hope/assume that the
>> user has some way of moving the mouse when they approach one of these
>> public kiosks.
>
> If MouseTweaks can solve the problem, that would be awesome.

It would be nice.  We really need to hear from users about whether this
would work or not.  If it does, then the worry about mouse gestures
might be for naught.  That would leave us with worrying about keyboard
gestures (which can be solved using the existing keyboard shortcuts
mechanism) and switch-based gestures.

>> Francesco's solution of offering a checkbox seems like it might work
>> and be rather simple.
>
> I worry this approach would be prone to error.  Users may not realize
> they need to set or unset the checkbox - especially if they launched an
> AT program via a keybinding rather than the a11y dialog.

Rather than two non-UI designers designing this, I think we need to pull
in the thoughts of UI-designers and end users about solutions that would
work.

> I do not think the environment variable approach is a very good one.  I
> just shared that past work for reference.  I think it makes more sense
> for GDM to set the user's GConf settings so that things work properly
> on login.  The trick is doing this in a way that the user's preferences
> never get messed up if the user has actually modified them.

Doing it in GDM would definitely allow it to have more knowledge and be
more flexible.  Do you have ideas for where in GDM we might be able to
do this?  Would it need to be in C code?  Would it be possible to have
it call out to some other module/script?

Will

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

> Agreed.  We have a mishmash of settings and config files across multiple
> areas, so I believe some hardcoding of stuff would probably be necessary
> (and perhaps brittle).

Just one additional thought on this -- a mantra I live by for Orca is to
let the user requirements drive the architecture rather than the other
way around.

So, I agree we should always strive to keep things clean from a
code/architecture perspective while we work to provide a compelling
experience for users.  But, all things being equal, I think the user
experience is more important than architectural onanism.

I also don't think we can just close our eyes and pretend to be blind,
or pretend we have limited mobility or pretend to be hard of hearing.
We really need to engage end users for help on what they would perceive
as a good experience.  So, we're discussing this in a good spot
(gnome-accessibility-list) and I'm encouraging end users to speak up
with their thoughts.

Will
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Francesco Fumanti]

Hi,

Willie Walker wrote:

>>> An issue which the carry over solution would solve is the very
>>> awkward method by which a11y needs to be enabled for the desktop.  
>>> Unlike gdm, which will have a11y enabled by default, the user session
>>> has a11y disabled by default.  So, if you can get an AT running
>>> during an inaccessible session, you really need to hope that the AT
>>> sets the a11y gconf flag and offers you with the ability to log out.
>>
>> It makes 100% sense to me for the setting of
>> /desktop/gnome/interface/accessibility to carry over to the user
>> session.  If the user launched an AT program in the login program, then
>> it would make sense for GDM to just go ahead and set this key for the
>> user session before starting it, for example.
>
> This would be a big plus.  The existing login/set_a11y/logout/login
> process is reasonable, but certainly not compelling.

+1

>>> The carry over would help ensure that the a11y gconf flag is set for
>>> the user if it is needed, making the user session accessible.  
>>> Imagine also that I needed high contrast large print inverse to log
>>> in.  It sure seems awkward to have to go through the theme selection
>>> process all over again once I login.  I think the carry over solution
>>> would be a much more pleasant out of the box experience.
>>
>> Right.  Although, providing keybindings and mouse dwell gestures to set
>> the a11y theme also seems a reasonable solution to avoid this sort of
>> setup.
>
> I'd like to shoot for the star that says "Compelling" on it rather than
> "Reasonable".  "Reasonable" usually ends up meaning "the minimal
> compromise we make to push a clunky solution."  I think we need to hear
> more from our end users about what they think would be compelling.

Indeed, I am not a friend of mouse gestures to start the onscreen
keyboard during GDM. Do we want to provide a solution only for the users
that are initiated, or do we also want to make it accessible for new users?
(I don't expect the average user to go and search for documentation; and
the help system shipped with the installation is not usable for a user
needing assistive tools until he has solved his accessibility problem.)


 From the point of view of a pointer user:

In GDM 2.28.x (probably also 2.26.x) it is possible to find out only by
looking at the screen that assistive tools are available, because of the
accessibility icon. Moreover, due to the accessibility dialog, he does
not have to hunt for an onscreen keyboard: it is only one click away
right in front of his eyes. And finally, GDM remembers the setup and
automatically starts the onscreen keyboard each time I get to the login
screen.  :-)

Personally, for pointer only users, I perceive the new GDM as a big
improvement in confront of the old GDM.


Unless I am making a mistake, Ubuntu Karmic is the first Ubuntu version
that is accessible out-of-the-box for pointer only users able to click.
Remarks:
- I am only talking about an installed Ubuntu Karmic; I don't know
whether a pointer only user will be able to go through the installation
process without help.
- I have named Ubuntu Karmic instead of GNOME 2.28 because I don't know
for sure how well gok will perform for pointer only users; Ubuntu Karmic
replaced gok with onboard.


GDM 2.28.x (and GNOME 2.28.x and Ubuntu Karmic) are not accessible out
of the box for pointer only users not able to click.

>>> I'm not 100% sure, but I think one of the more useful ones is the
>>> dwell gesture provided by MouseTweaks.  So, that can be resolved by
>>> putting the MouseTweaks applet in the panel and hope/assume that the
>>> user has some way of moving the mouse when they approach one of these
>>> public kiosks.
>>
>> If MouseTweaks can solve the problem, that would be awesome.
>
> It would be nice.  We really need to hear from users about whether this
> would work or not.  If it does, then the worry about mouse gestures
> might be for naught.  That would leave us with worrying about keyboard
> gestures (which can be solved using the existing keyboard shortcuts
> mechanism) and switch-based gestures.

You are trying to solve the problems by differentiating between
different needs instead of talking generally about "keyboard and mouse
gestures"; that is great as it is probably the better approach with
regard to the user.

Concerning pointer users that are not able to click without a software
click: I think that if the dwell click applet is installed by default on
the panel in GDM and if the dwell click applet is also installed by
default on the panel in the GNOME session, a GNOME desktop (GDM session
and GNOME session) would also be accessible for pointer only users not
able to click. (assuming the availability of an onscreen keyboard)

In fact, he will be able to left click, double click, drag click and
right click; he will be able to type. Is there anything that a user that
does not need any assistive tool can do what the pointer only user user
is not able to emulate through his assistive tools?


But who knows what use cases can exist that we have not imagined and
that breaks what we think to be a solution. That is why I add "I think
that" or "Unless I am making a mistake" to my sentences about solutions.

>>> Francesco's solution of offering a checkbox seems like it might work
>>> and be rather simple.
>>
>> I worry this approach would be prone to error.  Users may not realize
>> they need to set or unset the checkbox - especially if they launched an
>> AT program via a keybinding rather than the a11y dialog.
>
> Rather than two non-UI designers designing this, I think we need to pull
> in the thoughts of UI-designers and end users about solutions that would
> work.

Yes, the thoughts of UI-designers could be helpful.
+1

Cheers

Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Ian Pascoe]

Hi

I presume that DBus is not launched early enough  to act as a transport
mechanisum?  I wonder if into these current discussions thought should also
be made too to other desktop environments?  If DBus is launched at GDM, then
buy using this we aren't setting up yet another hash to achieve a result.

As a end user, I would like all the work I've done to setup accessible GDM
to be carried over to the desktop, thereby giving me accessibility straight
away from first log in.  I may have need to then add additional refinements
to my session profile that I may not want in GDM.  For instance as a
visually impaired user, I would want Orca to speak to me whilst I'm
navigating around the log in screen, but once into the actual desktop I may
want high contrast theme with magnification as well as speech.

So, I believe what is needed is a damen that gets launched as part of the
Gnome startup, which will receive from GDM the AT data.  It will then look
at the user's Session profile, and if no AT is selected it will instigate
the same AT as the GDM had.  If the user has set up further preferences,
like in the scenario above, it will then dump the GDM data and let the
normal startup work.

From a software viewpoint, maybe when GDM launches the session, it does so
with a particular flag set.  As the session starts if this flag is set it
will then launch the damon which will either accept the data from GDM over
DBus, or access the GDM profile, if it sees that that user has no AT set in
their profile already.  Otherwise, it will shutdown.

Ian

-----Original Message-----
From: gnome-accessibility-list-bounces@...
[mailto:gnome-accessibility-list-bounces@...]On Behalf Of
Francesco Fumanti
Sent: 04 November 2009 17:03
To: Willie Walker
Cc: Jon McCann; gnome-accessibility-list@...; Brian Cameron
Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm)


Hi,

Willie Walker wrote:

>>> An issue which the carry over solution would solve is the very
>>> awkward method by which a11y needs to be enabled for the desktop.
>>> Unlike gdm, which will have a11y enabled by default, the user session
>>> has a11y disabled by default.  So, if you can get an AT running
>>> during an inaccessible session, you really need to hope that the AT
>>> sets the a11y gconf flag and offers you with the ability to log out.
>>
>> It makes 100% sense to me for the setting of
>> /desktop/gnome/interface/accessibility to carry over to the user
>> session.  If the user launched an AT program in the login program, then
>> it would make sense for GDM to just go ahead and set this key for the
>> user session before starting it, for example.
>
> This would be a big plus.  The existing login/set_a11y/logout/login
> process is reasonable, but certainly not compelling.

+1

>>> The carry over would help ensure that the a11y gconf flag is set for
>>> the user if it is needed, making the user session accessible.
>>> Imagine also that I needed high contrast large print inverse to log
>>> in.  It sure seems awkward to have to go through the theme selection
>>> process all over again once I login.  I think the carry over solution
>>> would be a much more pleasant out of the box experience.
>>
>> Right.  Although, providing keybindings and mouse dwell gestures to set
>> the a11y theme also seems a reasonable solution to avoid this sort of
>> setup.
>
> I'd like to shoot for the star that says "Compelling" on it rather than
> "Reasonable".  "Reasonable" usually ends up meaning "the minimal
> compromise we make to push a clunky solution."  I think we need to hear
> more from our end users about what they think would be compelling.

Indeed, I am not a friend of mouse gestures to start the onscreen
keyboard during GDM. Do we want to provide a solution only for the users
that are initiated, or do we also want to make it accessible for new users?
(I don't expect the average user to go and search for documentation; and
the help system shipped with the installation is not usable for a user
needing assistive tools until he has solved his accessibility problem.)


 From the point of view of a pointer user:

In GDM 2.28.x (probably also 2.26.x) it is possible to find out only by
looking at the screen that assistive tools are available, because of the
accessibility icon. Moreover, due to the accessibility dialog, he does
not have to hunt for an onscreen keyboard: it is only one click away
right in front of his eyes. And finally, GDM remembers the setup and
automatically starts the onscreen keyboard each time I get to the login
screen.  :-)

Personally, for pointer only users, I perceive the new GDM as a big
improvement in confront of the old GDM.


Unless I am making a mistake, Ubuntu Karmic is the first Ubuntu version
that is accessible out-of-the-box for pointer only users able to click.
Remarks:
- I am only talking about an installed Ubuntu Karmic; I don't know
whether a pointer only user will be able to go through the installation
process without help.
- I have named Ubuntu Karmic instead of GNOME 2.28 because I don't know
for sure how well gok will perform for pointer only users; Ubuntu Karmic
replaced gok with onboard.


GDM 2.28.x (and GNOME 2.28.x and Ubuntu Karmic) are not accessible out
of the box for pointer only users not able to click.

>>> I'm not 100% sure, but I think one of the more useful ones is the
>>> dwell gesture provided by MouseTweaks.  So, that can be resolved by
>>> putting the MouseTweaks applet in the panel and hope/assume that the
>>> user has some way of moving the mouse when they approach one of these
>>> public kiosks.
>>
>> If MouseTweaks can solve the problem, that would be awesome.
>
> It would be nice.  We really need to hear from users about whether this
> would work or not.  If it does, then the worry about mouse gestures
> might be for naught.  That would leave us with worrying about keyboard
> gestures (which can be solved using the existing keyboard shortcuts
> mechanism) and switch-based gestures.

You are trying to solve the problems by differentiating between
different needs instead of talking generally about "keyboard and mouse
gestures"; that is great as it is probably the better approach with
regard to the user.

Concerning pointer users that are not able to click without a software
click: I think that if the dwell click applet is installed by default on
the panel in GDM and if the dwell click applet is also installed by
default on the panel in the GNOME session, a GNOME desktop (GDM session
and GNOME session) would also be accessible for pointer only users not
able to click. (assuming the availability of an onscreen keyboard)

In fact, he will be able to left click, double click, drag click and
right click; he will be able to type. Is there anything that a user that
does not need any assistive tool can do what the pointer only user user
is not able to emulate through his assistive tools?


But who knows what use cases can exist that we have not imagined and
that breaks what we think to be a solution. That is why I add "I think
that" or "Unless I am making a mistake" to my sentences about solutions.

>>> Francesco's solution of offering a checkbox seems like it might work
>>> and be rather simple.
>>
>> I worry this approach would be prone to error.  Users may not realize
>> they need to set or unset the checkbox - especially if they launched an
>> AT program via a keybinding rather than the a11y dialog.
>
> Rather than two non-UI designers designing this, I think we need to pull
> in the thoughts of UI-designers and end users about solutions that would
> work.

Yes, the thoughts of UI-designers could be helpful.
+1

Cheers

Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Francesco Fumanti]

Hi,

Francesco Fumanti wrote:

> Willie Walker wrote:
> Personally, for pointer only users, I perceive the new GDM as a big
> improvement in confront of the old GDM.
>
>
> Unless I am making a mistake, Ubuntu Karmic is the first Ubuntu version
> that is accessible out-of-the-box for pointer only users able to click.
> Remarks:
> - I am only talking about an installed Ubuntu Karmic; I don't know
> whether a pointer only user will be able to go through the installation
> process without help.
> - I have named Ubuntu Karmic instead of GNOME 2.28 because I don't know
> for sure how well gok will perform for pointer only users; Ubuntu Karmic
> replaced gok with onboard.

In the meantime, it occurred to me that I should have added that non
initiated pointer users able to click will probably be lost the first
time they enter the GNOME session as on a default Ubuntu Karmic
installation, the Universal Access menu and the menu items for the
onscreen keyboard (onboard) are hidden.

The carry over mechanism would solve the problem, but not hiding the
menus would of course be simpler.

Cheers

Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Francesco Fumanti]

Hi,

Brian Cameron wrote:
> It makes 100% sense to me for the setting of
> /desktop/gnome/interface/accessibility to carry over to the user
> session.  If the user launched an AT program in the login program, then
> it would make sense for GDM to just go ahead and set this key for the
> user session before starting it, for example.

+1

> Things get more tricky when you
> want to try and modify the user's configuration so that specific AT
> programs launch or themes get specified.  If we want this to happen,
> then we need to be careful to never mess up the user's configuration if
> they have set their AT preferences to meet their unique needs.
>
> For example, GDM could automatically set the GConf keys associated with
> the Preferences->Assistive Technologies "Preferred Applications" window,
> So, for example, if the user launches text-to-speech in GDM, then it
> might make sense to also set the "Visual" value to "Orca" and check the
> Visaul "Run at start" checkbox before starting the session.
>
> But doing this in a way that you are certain to not mess up the user's
> personal configuration may be hard.  Perhaps it would be reasonable to
> go ahead and set the GConf values for the text-to-speech case only if
> the "Run at start" GConf setting is unchecked.  Or to set the user's
> theme only if the user is currently using the system default theme.
> On first blush, this seems like it could work, but you really need to be
> careful when messing around with the user's preferences like this.

Indeed; this can become so complex that I wonder whether we should not
in any case leave the ultimate control to the user about whether to
carry over the assistive tools!? At least as a last resort for the user
in case the carry over mechanism screws up things that we missed (which
can be very probable).

>> The cases where I've seen end users wanting to start an AT from a
>> keystroke is for cases where they really want to restart the AT.  For
>> example, sometimes the a11y infrastructure hangs or an app hangs or
>> orca hangs.  The quickest way to unhang the system can be to restart
>> orca because orca clears up a bunch of stuff when it initializes.  So,
>> the user can create a custom keystroke to launch Orca via the
>> System->Preferences->Keyboard_Shortcuts dialog.
>>
>> However, I might be missing something, which is the case where a
>> gnome-session is *always* running, such as in a public kiosk.  It
>> seems to me that the System->Preferences->Keyboard_Shortcuts dialog
>> would provide at least some way to set up the AT's to launch via
>> keystrokes. That would then leave the non-keyboard related gestures
>> (e.g., the mouse enter/leave over boundaries gestures).
>
> Although the old GDM supported dwell gestures that involved enter/leave
> window boundries, this technique probably does not make sense for a more
> general solution that also needs to work in the user session.  The old
> GDM solution works well for GDM since we know that on startup that
> exactly one window is always present.
>
> For a more general solution, a different dwell gesture, like moving the
> mouse to a corner of the screen, or wiggling the cursor in a certain
> way, probably makes more sense.

The gesture solution supposes the user to be initiated about it. If we
succeed to provide a solution that works also for non-initiated users,
that would be very.

>>> Dealing with the complexities of making AT programs "carry over"
>>> while honoring the users personal preferences seems hard to implement
>>> correctly.
>>
>> Francesco's solution of offering a checkbox seems like it might work
>> and be rather simple.
>
> I worry this approach would be prone to error.  Users may not realize
> they need to set or unset the checkbox - especially if they launched an
> AT program via a keybinding rather than the a11y dialog.

Good point that the user might miss the checkbox. What about a popup
dialog that opens when the user has clicked the "Login Button"?

- Of course, the dialog would only pop up if the user activates an
assistive tool.

- The dialog could be user specific as GDM already knows the login name
of the user.

- The dialog would have a "Don't show this dialog again" option, which
should make sense as it can be user specific. Whether the "Don't show
again" setting should last forever or only as long as the user does not
change anything in the accessibility dialog of GDM is another point to
solve. To avoid problems, the latter might be better.

Does GDM not provide hooks for such a dialog?


> It seems better if this could be managed more in an automatic fashion.
> This should be possible, though I wonder if additional GConf keys may
> be helpful to help keep track of whether GDM should try to modify
> the user's configuration or not.

Some intelligence in the carry over mechanism is necessary even if GDM
asks the user whether to carry over the assistive tools: imagine a user
that tells GDM to carry over the assistive tools and they conflict with
another assistive tool that the user has configured to automatically
start at the beginning of the GNOME session.

Are we sure that it is possible to make the carry over mechanism
foolproof, even in the simpler approach where it is the user that
decides about whether to carry over the assistive tools from GDM to the
GNOME session?


Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Brian Cameron]

Francesco:

> Brian Cameron wrote:
>> Things get more tricky when you
>> want to try and modify the user's configuration so that specific AT
>> programs launch or themes get specified.  If we want this to happen,
>> then we need to be careful to never mess up the user's configuration if
>> they have set their AT preferences to meet their unique needs.
>>
>> For example, GDM could automatically set the GConf keys associated with
>> the Preferences->Assistive Technologies "Preferred Applications" window,
>> So, for example, if the user launches text-to-speech in GDM, then it
>> might make sense to also set the "Visual" value to "Orca" and check the
>> Visaul "Run at start" checkbox before starting the session.
>>
>> But doing this in a way that you are certain to not mess up the user's
>> personal configuration may be hard.  Perhaps it would be reasonable to
>> go ahead and set the GConf values for the text-to-speech case only if
>> the "Run at start" GConf setting is unchecked.  Or to set the user's
>> theme only if the user is currently using the system default theme.
>> On first blush, this seems like it could work, but you really need to be
>> careful when messing around with the user's preferences like this.
>
> Indeed; this can become so complex that I wonder whether we should not
> in any case leave the ultimate control to the user about whether to
> carry over the assistive tools!? At least as a last resort for the user
> in case the carry over mechanism screws up things that we missed (which
> can be very probable).

I think it does make sense for GDM to carry over a11y settings on the
user's first-time login.  However, to do this, we need a reliable method
to know when the user is logging in for the first time.  Since user's
can share the same $HOME directory across multiple machines, this can
be complicated.

What happens, for example, if the user shares the same $HOME directory
across two machines which have different AT tools installed, or two
machines that are running different distros.  Perhaps these sorts of
environments are too complicated to support well, but hopefully whatever
solution we implement does not break things badly in such environments.

>>> The cases where I've seen end users wanting to start an AT from a
>>> keystroke is for cases where they really want to restart the AT.  For
>>> example, sometimes the a11y infrastructure hangs or an app hangs or
>>> orca hangs.  The quickest way to unhang the system can be to restart
>>> orca because orca clears up a bunch of stuff when it initializes.  
>>> So, the user can create a custom keystroke to launch Orca via the
>>> System->Preferences->Keyboard_Shortcuts dialog.
>>>
>>> However, I might be missing something, which is the case where a
>>> gnome-session is *always* running, such as in a public kiosk.  It
>>> seems to me that the System->Preferences->Keyboard_Shortcuts dialog
>>> would provide at least some way to set up the AT's to launch via
>>> keystrokes. That would then leave the non-keyboard related gestures
>>> (e.g., the mouse enter/leave over boundaries gestures).
>>
>> Although the old GDM supported dwell gestures that involved enter/leave
>> window boundries, this technique probably does not make sense for a more
>> general solution that also needs to work in the user session.  The old
>> GDM solution works well for GDM since we know that on startup that
>> exactly one window is always present.
>>
>> For a more general solution, a different dwell gesture, like moving the
>> mouse to a corner of the screen, or wiggling the cursor in a certain
>> way, probably makes more sense.
>
> The gesture solution supposes the user to be initiated about it. If we
> succeed to provide a solution that works also for non-initiated users,
> that would be very.

I suspect a solution like a MouseTweaks applet being always available
would meet the needs of most users.  If there are use cases that are not
met well by MouseTweaks, then we should identify those and think about
what solutions are needed to provide support for those users.

>>>> Dealing with the complexities of making AT programs "carry over"
>>>> while honoring the users personal preferences seems hard to implement
>>>> correctly.
>>>
>>> Francesco's solution of offering a checkbox seems like it might work
>>> and be rather simple.
>>
>> I worry this approach would be prone to error.  Users may not realize
>> they need to set or unset the checkbox - especially if they launched an
>> AT program via a keybinding rather than the a11y dialog.
>
> Good point that the user might miss the checkbox. What about a popup
> dialog that opens when the user has clicked the "Login Button"?

That might work better.  However, we need to find the right balance
between providing needed functionality and making the a11y screen too
cumbersome to navigate.

> - Of course, the dialog would only pop up if the user activates an
> assistive tool.
>
> - The dialog could be user specific as GDM already knows the login name
> of the user.
>
> - The dialog would have a "Don't show this dialog again" option, which
> should make sense as it can be user specific. Whether the "Don't show
> again" setting should last forever or only as long as the user does not
> change anything in the accessibility dialog of GDM is another point to
> solve. To avoid problems, the latter might be better.

Yes, if the dialog were only shown if the user launched an AT program in
the login screen, this would probably be not too cumbersome.  If the
dialog has a checkbox that says "Don't show again", then this would also
be good.

GDM should probably also check to see if the user has already configured
that the AT program launched in the login screen be started in their
user session.  No reason to show the dialog if the user has already
configured this.

> Does GDM not provide hooks for such a dialog?

It probably would not be too hard to add code to GDM to support this
sort of feature.  GDM does provide the PostLogin and PreSession hooks.
The PostLogin script happens after authentication and the PreSession
hook happens before the user session starts.  You can launch GUI's like
zenity from these scripts, and this might meet your need.  Programs
launched from these scripts cause the login process to block until the
GUI exits, which is probably the behavior you want.

However, you need to be careful about doing this from an a11y
perspective.  You would need to test to see if any GUI's launched in
this manner work well with any AT programs that the user may have
launched in the GDM login GUI.

For example, it would be a problem if GUI's launched in this manner get
started after the AT programs are shut down.  If the user needed orca to
navigate the login GUI then they would also need it to work with any
GUI's launched from these scripts  You would need to test to see if
using these hooks to launch GUI's work properly.

If not, then there may be the need to add additional hooks to GDM, or to
fix whatever bugs might be causing this to not work properly.

>> It seems better if this could be managed more in an automatic fashion.
>> This should be possible, though I wonder if additional GConf keys may
>> be helpful to help keep track of whether GDM should try to modify
>> the user's configuration or not.
>
> Some intelligence in the carry over mechanism is necessary even if GDM
> asks the user whether to carry over the assistive tools: imagine a user
> that tells GDM to carry over the assistive tools and they conflict with
> another assistive tool that the user has configured to automatically
> start at the beginning of the GNOME session.
>
> Are we sure that it is possible to make the carry over mechanism
> foolproof, even in the simpler approach where it is the user that
> decides about whether to carry over the assistive tools from GDM to the
> GNOME session?

I suspect it is not possible to make things foolproof.  However, it is
probably possible to make things work well for users who use the desktop
in typical ways.  Even if the solution is not perfect it should be okay.
We should be careful that any solution is not destructive or make things
work much more badly for any corner-case users.

Brian
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Andre Nuno Soares]

Hello all,

Speaking solely as a blind user, I think this issue is being looked at
the wrong way.

The thought is: "A user shouldn't have to configure accessibility in GDM
and then again in the Desktop".

But the thought should be: "why does the user need to configure
accessibility (in the Desktop) if he already exists in the system?"

Accessibility is a requirement of the user, so it should be enabled when
the user is created in the system, just like enabling  the mounting of
the cd-rom drive, choosing the terminal shell  or allowing sudoing to
root.

This doesn't seem very complex to implement, but I don't know of any
Gnome setup that does it, and so we end up with accessibility being
configured twice when the user logs for the first time or soon after.

This makes even more sense if you consider "roaming profiles", be it in
a campus/corporate setup or the cloud.

AFAIK this doesn't exist in Gnome yet, but gconf at least already
supports LDAP and DB backends, and I think there are already some
experiences with roaming profiles.

For GDM accessibility, the proposed keyboard shortcuts/gestures would
solve the problem.


Just my 0.02€
André


_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

Hi André:

Thanks for joining in!

You won't get disagreement from me that what you mention would be a nice
solution.  Anywhere an interface is provided to add a new user to the
system (e.g., system installation, new user dialog, etc.) is an
opportunity to enable a11y appropriately for the user.  These are things
that have been on my wish list for a while.  :-)

Doing this will require cooperation from the distros to add a11y
features to their installers (e.g., Ubuntu's 'speech profile') and it
will also require a11y provisions to be added to the new user dialog.  I
believe both of the user interfaces to these touchpoints can be somewhat
distro-specific, however, so the solution can become somewhat complex
and likely to be error prone because not every distro is a responsible
a11y citizen.

I believe the GDM handoff to the user session tends to be somewhat
consistent across distros.  As a result, I think the carry over is a
touchpoint where GNOME can provide a consistent workable solution.

Also, the GDM carry over doesn't prevent the ability to add something
such as an "Accessibility" tab to the new user account dialog or to read
accessibility preferences from LDAP (or a USB stick, your
bluetooth-enabled mobile phone, etc. -- there's been work/research going
on in this space for a long time).  Instead, it should be a relatively
straightforward solution we can get to quickly.  The result will vastly
improve the current out-of-the-box experience for GNOME a11y and
increase the user's chance of being able to operate independently.

So, I'd view this as more of "low hanging fruit" that we can grab while
also shooting for tighter integration with user management.  I also
don't view it as something we'd end up eventually throwing away.  We can
never expect all distros to provide proper accessible installs and it's
doubtful all system administrators will make sure to enable a11y
preferences properly for new users, and it's doubtful we'll see generic
electronic a11y profiles appear until the proper committees have been
formed and some W3C or OASIS group anguishes over the file format for
years, and everybody ends up just ignoring the spec anyway.  ;-)

Will

Andre Nuno Soares wrote:

> Hello all,
>
> Speaking solely as a blind user, I think this issue is being looked at
> the wrong way.
>
> The thought is: "A user shouldn't have to configure accessibility in GDM
> and then again in the Desktop".
>
> But the thought should be: "why does the user need to configure
> accessibility (in the Desktop) if he already exists in the system?"
>
> Accessibility is a requirement of the user, so it should be enabled when
> the user is created in the system, just like enabling  the mounting of
> the cd-rom drive, choosing the terminal shell  or allowing sudoing to
> root.
>
> This doesn't seem very complex to implement, but I don't know of any
> Gnome setup that does it, and so we end up with accessibility being
> configured twice when the user logs for the first time or soon after.
>
> This makes even more sense if you consider "roaming profiles", be it in
> a campus/corporate setup or the cloud.
>
> AFAIK this doesn't exist in Gnome yet, but gconf at least already
> supports LDAP and DB backends, and I think there are already some
> experiences with roaming profiles.
>
> For GDM accessibility, the proposed keyboard shortcuts/gestures would
> solve the problem.
>
>
> Just my 0.02€
> André
>
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list