After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 303304 - GTK+ on win32 does not support MSAA
GTK+ on win32 does not support MSAA
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.4.x
Other Windows
: Normal enhancement
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-05-06 20:58 UTC by matt chisholm
Modified: 2018-04-15 00:32 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description matt chisholm 2005-05-06 20:58:21 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
Comment 1 Tor Lillqvist 2005-05-09 11:20:43 UTC
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.
Comment 2 Owen Taylor 2005-05-09 13:08:09 UTC
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.


Comment 3 Tor Lillqvist 2005-05-09 16:58:26 UTC
Thanks, Owen. (Presumably you wrote "CORBA" even though you meant OLE or COM?) I
agree that 1) seems like the best way.
Comment 4 Owen Taylor 2005-05-09 17:02:35 UTC
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.
Comment 5 Tor Lillqvist 2007-02-25 00:43:26 UTC
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...
Comment 6 SteveLee 2007-05-03 06:04:52 UTC
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.
Comment 7 Tor Lillqvist 2007-05-09 22:30:28 UTC
Thanks for the insightful comments.
Comment 8 Perry Werneck 2012-04-07 08:06:10 UTC
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;
Comment 9 Matthias Clasen 2018-02-10 05:08:31 UTC
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.
Comment 10 Matthias Clasen 2018-04-15 00:32:03 UTC
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