<div><span class="gmail_quote">On 6/26/06, <b class="gmail_sendername">Bill Haneman</b> <<a href="mailto:Bill.Haneman@sun.com">Bill.Haneman@sun.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Ashu:<br><br>Currently the state of KDE accessibility is somewhat limited. Other<br>than some important theming and keyboard-navigation support, which does
<br>not require a complex interface such as AT-SPI, there are only a few<br>useful utilities like KMag, KMouth, and KMousetool. While these are<br>nice utilities, they aren't enough to allow users who cannot use a<br>keyboard at all, or who are blind or have very limited vision, to use
<br>KDE.<br><br>We have three working screen readers (for blind users) for the free<br>desktop now; gnopernicus, orca, and LSR. For users who cannot use a<br>keyboard, we have GOK and Dasher. All of these technologies require the
<br>full power of the AT-SPI interfaces, and thus require the ORBit2 CORBA<br>stack in order to work. The gconf key you mention is for determining<br>whether support for such full-features assistive technologies should be
<br>enabled or not.<br><br>When KDE/Qt applications provide full-featured accessibility services,<br>as is planned for Qt4, then those services can be bridged to AT-SPI,<br>making those applications available to screen readers and other sorts of
<br>"user interface adapting" assistive technologies.<br><br>While it would be possible to write a "KDE" screen reader or KDE<br>onscreen keyboard for severely disable users (for instance users who<br>
cannot even 'point and click' reliably), I don't think it would be the<br>best use of our resources. Technologies like Orca are intended to work<br>with AT-SPI-enabled KDE apps just as they work with applications like<br>
OpenOffice, Java apps, Firefox, and other applications today, not just<br>"gnome". By writing Orca scripts for popular KDE applications, the KDE<br>desktop, and by fixing the inevitable bugs in KDE's keyboard navigation
<br>and accessibility support, a modest amount of development effort can go<br>further to benefit disabled users.<br><br>best regards<br><br>Bill<br><br>On Mon, 2006-06-26 at 13:30, Ashu Sharma wrote:<br>> On 6/26/06, Bill Haneman <
<a href="mailto:Bill.Haneman@sun.com">Bill.Haneman@sun.com</a>> wrote:<br>> On Mon, 2006-06-26 at 08:19, Ashu Sharma wrote:<br>> > Hi,<br>> ><br>> > There was discussion about making use of ATK on KDE, rather
<br>> than<br>> > putting in another CORBA implementation to talk to AT-SPI<br>> (to avoid<br>> > dependency on GNOME-related libraries). I'm not quite clear<br>> as to what
<br>> > was finally decided.<br>><br>> If KDE writes to ATK, it makes the job easier in a number of<br>> ways (at<br>> the cost of introducing a glib dependency, but hiding other
<br>> gnome-ish<br>> dependencies). However, the AT-SPI layer requires CORBA in<br>> order to<br>> function, so in order to actually expose useful information to<br>> our
<br>> assistive technologies, an application must LD_PRELOAD the<br>> "atk-bridge"<br>> module which bridges from ATK to AT-SPI's CORBA IPC.<br>><br>> I think this is the most effective thing to do for the time
<br>> being<br>> (preload atk-bridge), since it doesn't introduce a CORBA<br>> dependency on<br>> the KDE apps (only a soft runtime dependency). The AT-SPI<br>> assistive
<br>> technology clients cannot work without the AT-SPI/ORBit2/etc.<br>> libraries<br>> being present on the system anyhow, so from a practical<br>> perspective this<br>> is the minimum current dependency situation.
<br>><br>> There's another environment variable you can look for if you<br>> don't want<br>> to use gconf; GTK_MODULES. Of course that's still quite a<br>> gnome/gtk+-ish variable and arguably not appropriate to KDE
<br>> anyhow, so<br>> it might be cleaner just to spawn a gconf-client executable<br>> and parse<br>> the output, in order to detect whether assistive technology<br>> support is
<br>> desired or not. Also, soon there will be a slightly different<br>> mechanism<br>> for detecting the presence of the AT-SPI registry - it will<br>> place an IOR<br>> as an Xatom on the root DISPLAY window. This means you can
<br>> find it<br>> without using bonobo-activation.<br>><br>> regards<br>><br>> Bill<br>><br>> ><br>> > On a related note, is the gconf<br>> > key '/desktop/gnome/interface/accessibility' used on KDE
<br>> too, to set<br>> > or find if accessibility support is to be enabled on a<br>> system? Or, is<br>> > it used only on GNOME?<br>> ><br>> > Thanks,
<br>> > Ashutosh<br>> ><br>> ><br>> ______________________________________________________________________<br>> > _______________________________________________
<br>> > kde-accessibility mailing list<br>> > <a href="mailto:kde-accessibility@kde.org">kde-accessibility@kde.org</a><br>> > <a href="https://mail.kde.org/mailman/listinfo/kde-accessibility">
https://mail.kde.org/mailman/listinfo/kde-accessibility</a><br>><br>><br>><br>> Bill,<br>> Thanks for these details.<br>> I am actually wondering about the current state of KDE accessibility -<br>> whether AT clients under KDE currently depend on gnome/gconf libraries
<br>> (especially if they use the gconf key<br>> '/desktop/gnome/interface/accessibility' to enable AT support) .<br>> Thanks,<br>> Ashutosh<br>><br>><br>> ______________________________________________________________________
<br>> _______________________________________________<br>> kde-accessibility mailing list<br>> <a href="mailto:kde-accessibility@kde.org">kde-accessibility@kde.org</a><br>> <a href="https://mail.kde.org/mailman/listinfo/kde-accessibility">
https://mail.kde.org/mailman/listinfo/kde-accessibility</a><br><br></blockquote></div>
<div><br>Hi Bill,</div>
<div> </div>
<div>These details are really useful. Thanks!</div>
<div>I suppose things will get much better on KDE after Qt4 or with more application specific Orca scripts.</div>
<div> </div>
<div>Thanks,</div>
<div>Ashu</div>