Re: GDM accessibility sans AT-SPI

[Brian Cameron <Brian Cameron Sun COM>]

Bill:

> > Another controversial post to g-a ...
> >
> > I'm currently looking at GDM accessibility and it strikes me that there 
> > is a strong case for doing this without using AT-SPI. The themed version 
> > currently does not work properly with the AT-SPI features and on the 
> > plain greeter version there is still a fair amount of configuration 
> > required.
> >   
> Actually by "themed version" you are referring to branding-type themes; 
> the existing gdmlogin screen DOES work quite well with 
> accessibility-related themes, for instance large print, high contrast, 
> inverse, etc. etc.

I believe Henrik is talking about enhancing gdmgreeter so that you can
easily switch to accessible themes.  Yes switching to accessible themes
already does work okay using gdmlogin.

> > Both the AT-SPI framework and the assistive apps are complex things that 
> > will need some work to get working Just Right at the login. It also 
> > takes some time to load. AT-SPI is great for global desktop access since 
> > adding access to every single app would be silly. However, GDM is *not a 
> > desktop app* and also has a simple and predictable interface so it makes 
> > sense to look at other options.
> >
> > I've written a spec describing a login system with built-in access support.
> > https://wiki.ubuntu.com/Accessibility/Specs/GdmAccessLite
> >
> > This may not be the right way to go but I think we should consider it 
> > before starting work on fixing the current model.
> >   
> I don't know what needs to be "fixed" in the current model.  I also 
> don't think it practical to try to build accessibility into the GDM 
> greeter without allowing the use of assistive technologies, and the 
> latter functionality clearly requires AT-SPI.
>
> As I see it, the accessibility issues and use cases at login are largely 
> the same as the ones that apply when the desktop is posted.  Therefore, 
> the same fix (i.e. AT-SPI) is appropriate.

For gdmgreeter, which supports theming, it makes sense to support
the magnifier or High/Low Contrast themes that the user can easily
switch to (e.g. via a hotkey).  Rather than supporting magnifier,
supporting themes with larger fonts or being able to simply increase
and decrease the font in the current them via hotkey is probably
better than supporting the half-screen magnifier.  This is because
gdmgreeter is not designed to use a STRUTS enabled window manager
and this would be harder to get working with gdmgreeter than just
being able to modify the font size.

Again, it would be important to be able to increase/decrease fonts
in a way that works with gdmchooser, gdmsetup, and dialogs...not just
the gdmgreeter theme by itself.

Brian