Reece,<br><br>I have to agree with you on the idea of just using UIAutomation and then using the MSAA bridge/proxy for MSAA support in the end. This leaves only one implementation in wine, requires only one to be implemented. It's likely that eventually MSAA will be phased out. Although since MSAA is already partially implemented would it be worth it to finish it up first? Then there would be support for most accessibility application while we work toward UIAutomation support.<br>
<br>Tying into ATK/AT-SPI or other a11y protocols so that there is native support for wine and those using it is a great idea! Although I think getting MSAA/UIAutomation is the first step, I think supporting both is a great idea. Another thought is to look at mono accessibility and it's goal of bridging UIAutomation and AT-SPI. I'm not really sure how far along they are or where they have gotten with it, but it should provide some good ideas. I don't think we should rely on it, but using it as a reference can't hurt.<br>
<br><br>-Seth<br><br><br><div class="gmail_quote">
On Tue, Oct 12, 2010 at 10:55 AM, Reece Dunn <span dir="ltr"><<a href="mailto:msclrhd@googlemail.com" target="_blank">msclrhd@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>
<br>
</div></div>The current wine implementation supports GetRoleText and the like on<br>
oleacc.dll, but does not support IAccessible (MSAA) or UIAutomation<br>
functionality on the Win32 objects (windows, list boxes, text edit<br>
controls, buttons, etc.).<br>
<br>
UIAutomation consists of 4 parts:<br>
� 1/ �a COM API to the accessibility functionality<br>
� 2/ �UIAutomation support for all Win32 controls<br>
� 3/ �an MSAA <=> UIAutomation bridge (for applications that use MSAA)<br>
� 4/ �a .NET binding to the UIAutomation objects<br>
<br>
To get MSAA working in wine, you will need to (minimally):<br>
� 1/ �complete the IAccessible core support -- LresultToObject and friends<br>
� 2/ �add a WM_GETOBJECT handler to all the Win32 controls and expose<br>
IAccessible COM objects (with tests!)<br>
� 3/ �implement/flesh out the WinEvents API to get the IAccessible<br>
objects for the events<br>
<br>
Given the move to UIAutomation, it would be easier in terms of<br>
implementation to:<br>
� 1/ �expose UIAutomation objects via the WM_GETOBJECT message<br>
� 2/ �use the MSAA <=> UIAutomation bridge to support MSAA<br>
<br>
A question here is whether the wine MSAA/WinEvents/UIAutomation<br>
implementation should bind to the Gnome/KDE accessibility APIs<br>
(GAIL/???). The benefit here is that the Windows applications will<br>
integrate into the native Linux a11y technologies. The problems here<br>
are (a) getting Alexandre's buy in to use the GAIL APIs if present and<br>
(b) whether these are going to change in the move over to Gnome3.<br>
<br>
In terms of applications to test, Firefox supports at least MSAA<br>
bindings as do Qt applications. Others will to, to varying degrees<br>
(some relying on the native Win32 support), but FF and Qt implement<br>
their own IAccessible bindings.<br>
<br>
In terms of testing this via applications (in addition to the<br>
regression tests that will need to be provided), there are various<br>
assistive technologies that make use of MSAA/UIAutomation -- JAWS,<br>
Dragon Naturally Speaking, etc. I am not familiar with NVDA.<br>
<font color="#888888"><br>
- Reece<br>
</font></blockquote></div><br>