[no subject]

Ian

-----Original Message-----
From: gnome-accessibility-list-bounces gnome org
[mailto:gnome-accessibility-list-bounces gnome org]On Behalf Of
Francesco Fumanti
Sent: 04 November 2009 17:03
To: Willie Walker
Cc: Jon McCann; gnome-accessibility-list gnome org; 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 gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list