On Fri, Mar 07, 2008 at 12:44:13PM -0600, Brian Cameron wrote: > Most existing a11y programs (such as orca and GOK) depend on the > ability to snoop on dialogs to report what is going on in other ways > (text-to-speech), and to allow users to control the GUI via alternative > input programs such as GOK (on-screen keyboard). > > If we make the password entry dialog inaccessible to snooping, then > we also make it inaccessible to AT programs. > > However, as has been pointed out before, the UI for entering your > password is not really that complicated, so a reasonable solution > to provide a11y might be as follows:
The AT programs that are needed for a11y have to become trusted components of the trusted path, or have to be shut out of the trusted path, losing whatever a11y functionality they provide. I'm guessing the latter is not acceptable. A solution that uses multiple processes to run different parts of the UI won't work either -- suppose we put PAM prompts/messages in a process that can use text-to-speech and magnification a11y outside the trusted path, but make sure that username and password entry happen in a path that includes keyboard a11y. Well, then any process with access to the user's xauth can then muck with PAM's messages to the user. Not good. So all of the a11y infrastructure has to become part of the trusted path. > 1) Embed an onscreen keyboard directly into the dialog, much > like gnome-screensaver already supports: > > http://bugzilla.gnome.org/attachment.cgi?id=69696&action=view > > 2) Instead of providing magnification, it might be sufficient to > just provide a hotkey that increases/decreases font size in the > dialog. And the ability for the user to configure the default > font size. Right, some a11y features can be avoided. > 3) Some ability to launch text-to-speech, mMuch the same as GDM > currently allows you to hit a hotkey to turn this on. Or we > could allow the user to configure that this is on by default. > Or we could try to detect if the user is running orca, and > assume they want to run it in the dialog as well. Text-to-speech cannot be avoided. Orca will have to be part of the trusted path. Same thing for sticky/repeat/slow/bounce/mouse keys. > 4) Some ability for the dialog to detect and honor whatever > theme is being used by the user, so if they are using a high > or low contrast theme, this isn't lost when they go to the > lock screen dialog. Perhaps the userland eyecandy program > could communicate the theme to the background daemon. Themes are not an a11y requirement, are they?
