GNOME Bugzilla – Bug 303304
GTK+ on win32 does not support MSAA
Last modified: 2018-04-15 00:32:03 UTC
MSAA is the standard screen-reader API for accessibility for blind people under win32. 1) build a gtk app on win32 2) use windows MSAA to try to read the widgets from win32 Some info about MSAA: http://www.mozilla.org/access/windows/msaa-server#intro
I don't know if a11y is even supposed to work using just GTK+. There is an extra layer, gail (GNOME Accessibility Implementation Library), that interfaces atk and GTK+, or something like that. gail (HEAD from CVS) builds on Win32 out of the box, but I haven't really tested what it does. How does a11y for GTK+ work on X11? Is it gail that needs to be made MSAA aware and not GTK+ itself? On the other hand, gail doesn't contain any X11- or Unix-specific bits either, so it doesn't seem right that MSAA-specific changes would belong in it. I don't really understand how all this is supposed to hang together. I'll read that Mozilla documentation and see if it makes me any wiser.
Basic situation: ATK - set of accessibility interfaces gail - glue layer that provides ATK interfaces for GTK+ (some cases ATK implementatoin is in GTK+ proper ... we'll probably move more that way in the future) [ a loadable module ] ATK is only in-process, so another piece is needed bridge ATK to CORBA so that it can be used from accessibility apps like screen readers atk-bridge: Bridges ATK to CORBA [a loadable module] AT-SPI: Interface used by accessibility apps So, without looking at the details of MSAA, there are two basic ways that a11y could be implemented in GTK+ for windows: 1) Create a atk <=> msaa bridge 2) Implement msaa from scratch in the GTK+ widgets If 1) is possible, it clearly far less intruisive on the GTK+ code structure. Extensions to ATK can presumably be made if necessary.
Thanks, Owen. (Presumably you wrote "CORBA" even though you meant OLE or COM?) I agree that 1) seems like the best way.
No, I was describing the approach on Linux/Unix, where CORBA is used. My guess is that an atk <=> msaa bridge would be entirely in-process.
BTW, in case I start hacking on this, is the Narrator included with XP and the accexplorer32 and inspect32 tools downloadable from MSDN sufficient tools to test with? Or should one ask nicely for a free copy of some commercial screenreader, hopefully companies making those are interested in having their products interoperate nicely with GTK+ apps...
Here's a couple of presentations from Bill Haneman, the AT-SPI lead (retired) that may help to answer some of the questions http://www.gnome.org/~billh/ArchitecturalOverview.odp http://www.gnome.org/~billh/ApplicationImplementation.odp Porting involves some complexity as for example Mozilla support ATK on linux but bypass this for MSAA rather than using a bridge. The mozilla and gnome accessibility communities should be good places to start. As a point of information IAccessible2 has entered the picture as an enhancement to MSAA that looks much like AT-SPI and thus reduces the gap on Windows between ATK and a11y api. MSAA has extremely limited functionality compared to that of Linux accessibility. Microsoft's replacement for MSAA, UI Automation, requires .NET managed code, though they are touted to be changing that due to pressure. As a result many of the AT vendors have supported IA2, along with IBM. IA2 is an open standard and though Windows-centric is managed by the Linux foundation http://www.linux-foundation.org/en/Accessibility/IAccessible2. It's early days for IA2 so application support is even more patchy that MSAA. However as it extends MSAA you'll need MSAA support anyway. Mozilla are working on IA2 support and it may land in Firefox 3.0.
Thanks for the insightful comments.
A bridge ATK<->MSAA can be done but, I think, it will need a small change in gdkevents-win32.c. I just started the development of the bridge using gdk_window_add_filter to filter WM_GETOBJECT message; the problem is: I need to return an LRESULT value on this message and seens like the inner_window_procedure inside gdkevents-win32.c allways return "0" on filtered messages. I´m suggesting a few changes: converting the original MSG structure to an extended one with the return code, this allow the message filter to change the result value and keeps compatibility with the current methods. On line 251: MSG msg; DWORD pos; gint ret_val = 0; Change to: struct extended_msg { MSG msg; gint ret_val; } DWORD pos;
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new