Higher level accessbility abstraction layer

[alfredpeng]

wxWidgets utilizes the native platform's controls and utilities to provide easy-to-use API for writing GUI applications on multiple platforms. On Solaris for example, it uses GTK widgets and control. For better A11Y support, a GTK-based application needs to follow the guidance here:  http://live.gnome.org/GAP/AtkGuide/GtkAtk#_Toc412398981. That's to say, to use GTK+ widgets and ATK together to build a real accessible GTK+ application.

Currently, wxWidgets, a cross-platform library, doesn't have any atk related implementation and it only provides basic level of A11Y support comes from GTK. It needs to provide a translation layer to pass all the a11y related information from the GUI applications to the lower level libraries(GTK on Solaris/Linux) so that the applications with good widgets name and description(etc.) could have better a11y support.

Not sure whether base is the correct component for this. Please feel free to reassign to the correct one.

[yippi]

To provide a bit more information.

Note that the wxWidget set uses GTK+, so it is mostly accessible out of the box. However it doesn't provide access functions so that applications can set accessible descriptions, labels, or relations. In other words, programs built using wxWidgets would likely be partially or mostly accessible, but might have some issues that would require fixing the wxWidgets set library to address.

You can refer to the ATK interfaces to see how to write interfaces that would allow application writers to call the needed functions to set accessible descriptions, labels, and relations. Also, the following link has documentation which explains the interfaces application writers need in order to make their programs fully accessible:

 http://live.gnome.org/Accessibility/Developers

In testing FileZilla, for example, we noticed a number of issues where it wasn't accessible. As an example of a wxWidgets program, this input might hopefully highlight areas where work is needed.

1. Toolbar accessibility

The toolbar of filezilla is not accessible to orca. And it doesn't
support keyboard navigations either. The features of buttons in this
toolbar are not available in top menu. So this is a big problem.

Good news is this toolbar is accessible to gok.

2. Panel accessibility

Each panel in filezilla main frame supports keyboard navigation, and
it also reflects the current focus changes, but it can not expose
focused item to at-tools, including orca and gok.

Queue panel is an exception, it neither supports keyboard navigation
nor other at-tools accessing.

3. Settings frame accessibility

Setting frame supports keyboard navigation with exceptions. When this
frame is invoked first time, focus can not be changed with keyboard
only. Mouse clicking is needed to put focus into different panels,
say left tree view panel. After that, keyboard navigation works just
fine.

This also leads to the orca accessing problems due to failure of
keyboard navigation. At the same time, panel problems as I mentioned
in section 2 are also visible here.

4. Warning dialog accessibility

Warning dialog does not support keyboard navigation, this also blocks
blind accessing.

5. Others:

HCLPI theme and magnifier can be supported.

[vadz]

We obviously do need it but unfortunately we (with the possible exception of Julian?) don't know much about this and so it risks to be difficult implementing this without outside help. We'd gladly accept any such help and the practice shows that after the initial impetus, the code can be maintained without too much trouble (as happened with e.g. RTL support) but we're unlikely to be able to implement this ourselves in the near future, sorry.