Nicolas Williams wrote: > 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.
Let me explain more clearly. - magnification could be handled by simply providing a hotkey to increase/decrease font sizes, and being able to configure a default. - on-screen keyboard could be managed by directly embedding an on-screen widget into the dialog. This could mean simply providing simple buttons on the dialog that allow the user to type letters (either by clicking on them or hovering the mouse over them for a period of time). Or we could do what gnome-screensaver does, and embed a program like matchbox-keyboard that does the same thing, if it is acceptable to add a module like this to the Trusted Path. - To provide text-to-speech and braille display support, it would probably be necessary to pass strings back to the userland lock screen process to tell it what to speak and display on the lock screen program (if the user is running orca). So, the password dialog running as root would pass strings like "Enter your password" or "Your password is invalid" or whatever PAM returns to the userland process so they get read and shown on the braille display. Since the login dialog and PAM are in control of these strings, I don't think this would affect trusted path. - To provide theming support, it would be necessary for the dialog to be informed of what GNOME theme is being used, so if a HighContrast theme is being used, this can be also used in the dialog. Since such theming is a part of GTK+ already I don't think this would add anything more to the trusted path than GTK+ itself. Note the above approach does have its drawbacks. The biggest problem with embedding control like this into the dialog directly is that not all AT features will be supported. GOK, for example, may support some features that some people depend upon, and getting the same support in an embedded on-screen widget could be a lot of work. Also, if a new AT program is written to help people with a particular disability, then we may need to do extra work to embed similar functionality into the lock screen dialog, or not support users with that disability. However, it is probably less work to embed features into the lock screen program than to add new programs into the Trusted Path, I'd think. Also, this is probably not such a big concern. The UI of the lock screen dialog is very simple, and most users can probably navigate their way through entering their password without having as much assistance as they might need in their actual desktop session. But providing a mechanism to support text-to-speech, braille display, theming, magnification, and on-screen keyboard is a reasonable level of support, I think, and would meet Section 508 Requirements. >> 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. I don't think this is the case if the dialog passes strings to the userland eye-candy program and these are passed along to orca. Since the lock screen dialog and PAM have control over the strings displayed, we know no sensitive information would ever be passed along. The only way this would happen is if PAM passed a message back saying your password or something, which should never happen. > Same thing for sticky/repeat/slow/bounce/mouse keys. Since these features are provided by the Xserver, you should be able to do things like hit the shift key 5 times to automatically enable StickyKeys, or whatever hitting the shift key 5 times enables. >> 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? Yes, users with low vision require a High Contrast Theme, for example. However, GTK+ theming support is a part of GTK+ and should not add anything more to the Trusted Path. If this were a problem, you can provide things like High Contrast theming without using GTK+ themes. You could, for example, set all the gtk resources by hand, but this doesn't seem worth the bother to me. Brian
