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
