Opened 6 years ago

Last modified 6 years ago

#9785 confirmed enhancement

Higher level accessbility abstraction layer

Reported by: alfredpeng Owned by:
Priority: normal Milestone:
Component: GUI-all Version:
Keywords: accessibility Cc: utensilcandel@…
Blocked By: Blocking:
Patch: no

Description

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.

Change History (3)

comment:1 Changed 6 years ago by 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.

  1. 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.

  1. 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.

  1. Warning dialog accessibility Warning dialog does not support keyboard navigation, this also blocks blind accessing.
  1. Others: HCLPI theme and magnifier can be supported.

comment:2 Changed 6 years ago by vadz

  • Component changed from base to GUI-all
  • Keywords accessibility added
  • Status changed from new to confirmed
  • Summary changed from wxWidgets needs a cross platform translation layer for better a11y support to Higher level accessbility abstraction layer

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.

comment:3 Changed 6 years ago by Utensil

  • Cc utensilcandel@… added
Note: See TracTickets for help on using tickets.