Re: Vetruvian icon on a locked screen



I agree as well.  I can also imagine a shared machine much like the one I have in my kitchen.  With this machine, there is a "switch user" option on the locked screen that allows me to get access to my account even if someone else has walked away from the machine without logging out.  In this case, someone with a disability coming up to the locked desktop would need some way to at least be able to activate the "switch user" button to get to a new login screen.

So, a consistent a11y mechanism for the login screen, user desktop, and screen lock seems like it would make a lot of sense.

Will

On Feb 8, 2010, at 1:09 PM, Brian Cameron wrote:

> 
> Francesco:
> 
>> However, from the perspective of the pointer only user, there is at
>> least one additional topic that has to be taken into account: how should
>> he start the onscreen keyboard when the desktop gets locked after a
>> period of inactivity.
>> My first idea would be to add the vetruvian man icon, that is already
>> available in GDM, also to the locked screen.
> 
> Yes, it would make sense for the lockscreen program to provide an a11y
> menu for launching AT programs.  It would also make sense for it to be
> configurable so that users can set it up so that needed a11y programs
> are automatically launched each time the lockscreen is displayed.  For
> example, if the user has the on-screen keyboard configured to be
> automatically started in their user session, then it seems sensible that
> it should also be available when the lock screen is dislayed.
> 
>> Among the things that have to be determined are:
>> - What are the applications that are shipped with GNOME that can lock
>> the screen? (One of these applications is probably the screensaver.)
> 
> VT switching also locks the screen when you switch away from a running
> user session.
> 
>> - I can imagine that some assistive tools (maybe the screen reader for
>> example) remain active, even if the screen gets locked.
> 
> Note that from a Trusted Path perspective, you really do not want
> programs running as the user to interact with programs that ask for
> things like system passwords.  Ideally, the lockscreen GUI should be
> run as a different user than the user whose session is locked.  In
> this sort of setup, you would not want the a11y programs running in
> the user session to be able to interact with the lock screen, and
> would instead want them to be relaunched.  However, this could be done
> automatically so that the user wouldn't notice the switch.
> 
> Currently, the lock screen programs do not work this way, but it
> probably makes sense to work towards designing a next generation lock
> screen that better meets both a11y and Trusted Path requirements.
> 
>> Consequently,
>> one might argue that the vetruvian man icon with its corresponding
>> dialog to enable the assistive tools might be overkill for a locked
>> screen.
> 
> Not at all.  It is important to provide users with the ability to
> configure a11y features for the lock screen.  I believe gnome-
> screensaver already has interfaces for setting it up to work with
> on-screen keyboards.  Check out the gnome-screensaver FAQ:
> 
> http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#Can_I_embed_an_on-screen_keyboard_for_use_with_mobile_devices.3F
> 
>> One the other hand however, one could also argue that using the
>> same dialog as the dialog used during GDM would not only reduce code
>> redundancy, but would also give a constant user interface to enable
>> accessibility in GDM and on a locked screen. Or could there be any
>> reason for not offering the full choice of assistive tools to the user
>> during a locked screen?
> 
> But, as you say, much more could be done.  An a11y dialog like
> what is used in GDM would be a big improvement for the lockscreen.
> 
> Brian
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list



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