"The only way accessibility could be handled is by creating a base framework (from the GTK, or QT or JSwing or any other GUI toolkits) that provides accessiblity "features to the interfaces. This means that the application developers will not need to "worry (too much) about accessibility because the "text control" will contain the features "by default*(and this is the "most-most-important-issue"*
This is exactly what we've done (with GTK+ and, originally, Swing; KDE/Qt are following suit). In reality it's still easy for developers to inadvertantly break stuff, but at least stock widgets do the right thing. However, the other requirement is that somebody (i.e. the assistive technologies) are listening to the accessibility interfaces provided. That's why the toolkits above are more accessible on the FOSS platforms (GNOME, etc.) than on the Windows platform at present - Windows ATs have historically focussed on eavesdropping on proprietary Win32 APIs, out of necessity, and have tended to focus resources on custom support for the apps with the 'largest market share'.
Now that the built-in support is maturing, things are getting better on the FOSS platforms fast, though there's a lot of catching up to do for some user groups.
Bill Haneman
Gnome Accessibility Project
