Agreed with Peter and Bill, why re-invent the wheel? Takeing this to the next logical step.
If you have a normal un-disabled user they would not want AT-SPI or similar technology launched at this point, only those of us who need it. I don't know how practical or codeable it would be but if prior to log on you could set the code to examine the users built on the system and if the user profile has Assistive Technologies enabled you start the AT-SPI and required apps before log in. OK, next question what about multi user systems? Again I think if any of the users have Assistive Technologies enabled you would need to load that up as default as until the log in screen is completed you won't know which user is logging in. At After log in AT-SPI could either be killed or left running. Obviously if this marker was not set then you progress as normal. Maybe also some type of indicator on the dialogue box as well to show that Assistive Technologies is activated and runing too? Just a few more thoughts for the melting pot. Ian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Korn Sent: 07 December 2006 19:25 To: Henrik Nilsen Omma Cc: [email protected] Subject: Re: GDM accessibility sans AT-SPI Hi Henrik, Login is a somewhat unique environment; it is reasonable to explore the question of whether one can get by without AT and AT-SPI. Unfortunately, I think the answer is "it depends upon the disability need", which ends up being essentially "no, you can't really do without it". You can do contrast & theming of course. And the AccessX suite of tools. You can attack speech at login in the same was as you might attack it at gdm time -> play .WAV files. You can also making the app self-voicing. Given how simple the login screen is, the advanced features of GOK aren't that important. However, how do you address Braille? How do you address multiple disabilities? What do you do when have additional AT we want to use (e.g. voice recognition)? And how much work will it be to make login self-voicing? How does that quantity of work compare to just supporting AT-SPI and ATs at login? Given all this, I think it makes more sense for doing with AT-SPI. If we are concerned with startup time, why not load a simple gesture listener (should be quick) that when activated restarts gdm login with a specific AT loaded? I think we should at least explore options of addressing the concerns you start to list below before (or in parallel to) working on a self-voicing login. Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. > Hi all, > > 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. > > 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. > > Henrik > _______________________________________________ > gnome-accessibility-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
