Aaron Leventhal indicated that there were some questions about UI Automation and its cohabitation with IAccessible2.
Currently, no major assistive technology vendor (ATV) supports UI Automation (UIA). UIA is divided into a provider (application) and client side (ATV) API. The client side portion runs in managed code (.NET, c#, etc.). Today UIA requires ATVs to rewrite all or part of their software to run a managed environment. This has prevented ATV adoption of UIA. Microsoft claims to be writing an unmanaged client-side UIA implementation piece which ATVs can support but that is post Vista ship. Given that this has not been provided yet, and extremely few applications even support UIA,, we believe UIA really needs much more testing with ATVs to prove that is ready for wide scale adoption. Microsoft's challenge will be to get large applications, like MS Office, and ATVs to support UIA and work out any defects.
Now, all this said, the Vista desktop needed to be accessible so today Vista access by screen readers is a combination of MSAA and screen scraping. In short, access to the Vista desktop is like XP. Last year Microsoft spent a significant effort adding the ability for screen readers and magnifiers to capture information drawn to the desktop to reproduce what is on XP. This capability is limited to the unmanaged environment. Microsoft has done some mapping back to MSAA from managed code to support basic MSAA and some text access but it is limited. Consequently, support for unmanaged applications will depend on a client side unmanaged API layer. Due to the limited number of managed applications there is little business justification for ATVs to support them.
We do believe that more work will be required for application vendors to switch from MSAA to UIA. With IAccessible2 we complement MSAA, as is, and we have fully tested ATV support today. Also, the effort to enable IAccessible2 enabled applications on other platforms is significantly smaller. We have heavily tested and designed IAccessible2 to work on an entire office suite and with input from the Mozilla foundation. IAccessible2 is not new in that it is derived from APIs we helped designed for UNIX and Java and which we have been working for some time. IAccessible2 was designed with the help of ATVs like Freedom Scientific and GW Micro during its implementation on IBM's new office suite. Please my blog below for more information on the Missouri project. We are also developing next generation tooling to support IAccessible2.
UIA has also not been designed to support ARIA and so changes to UIA may be required to support it. Going forward IAccessible2 is an open standard and will allow others in industry to enhance it as new technology warrants it. Proprietary APIs are much more restrictive and this kind of participation is very difficult. We believe they can both coexist on the same platform as both are built on top of COM.
The significant value add of IAccessible2, for ATVs, is we do allow them to continue to run in process to get the performance enhancements they have realized with MSAA. This may prove difficult with the provider/client architecture in UIA.
In short, we believe the two will coexist but because UIA has not been used by major application vendors and ATVs we believe it will take some time to be fully realized. In the meantime IAccessible2 will already have been implemented to support large, rich, desktop applications and ARIA with full ATV support. UIAs immediate value add will be for managed applications.
Beyond Mozilla's planned IAccessible2 support in Firefox 3 and our implementation in our Notes 8 productivity editors which support ODF we will be adding support in Eclipse. That work has just kicked off. By implementing it in Eclipse any application built using Eclipse will be able to make use of IAccessible2 and richer access. This will ultimately allow us to do rich model-based authoring tools in our Rational product line, and so on. Many vendor's products work on Eclipse, ... IBM, SAP, etc.
There are other toolkit vendors and platform vendors planning to support IAccessible2 and I hope they will be making those announcements in the near future.
How radically different are the roles exposed by UI Automation and IAccessible2? Would it be possible/useful to create some sort of mapping between them? (Smaller application developers may baulk at developing applications that expose to multiple accessibility frameworks.)
The roles and properties are not radically different between UIA and IAccessible2/AT-SPI, but unfortunately all accessibility API's have some differences in those areas.
More specifically, IBM was part of the original UIA review process, and while use of roles is not exactly the same as in AT-SPI and IAccessible2, we believe a mapping is possible. The review was under NDA so we can't discuss the details.
Microsoft planned for companies to write adapters to UIA. We would be happy to work with Microsoft to support a cohesion in the future if needed. We would like the work to be done in an open standards venue.
Benjamin Hawkes-Lewis wrote: > How radically different are the roles exposed by UI Automation and > IAccessible2? Would it be possible/useful to create some sort of mapping > between them? (Smaller application developers may baulk at developing > applications that expose to multiple accessibility frameworks.)
Hi Rich, Thank you very much for the clarification, particularly with regards to UA. I guess, what makes it hard sometimes is the kind of information you provided is not readily available off MS sites. Thanks again, Victor
Thanks Rich, hmm it sounds the actually position with UIA is not quite as rosy as it is presented. I also get a feeling that UI automation is aimed at the testing market to a large extent, though that is not necessarily a bad thing for accessibility.
>We believe they can both coexist on the same platform as both are
built on top of COM.
I guess that MS will be supporting COM for a long while even though they prefer us to go managed. The fact that MSAA uses win events and not COM events might be a slight risk but again support will be around for a long time.
Having IAccessible2 support in code created by toolsets is excellent. Will the tools expose IAccessible themselves to allow developers to use AT?
> Aaron Leventhal indicated that there were some questions about UI > Automation and its cohabitation with IAccessible2.
> Currently, no major assistive technology vendor (ATV) supports UI > Automation (UIA). UIA is divided into a provider (application) and client > side (ATV) API. The client side portion runs in managed code (.NET, c#, > etc.). Today UIA requires ATVs to rewrite all or part of their software to > run a managed environment. This has prevented ATV adoption of UIA. > Microsoft claims to be writing an unmanaged client-side UIA implementation > piece which ATVs can support but that is post Vista ship. Given that this > has not been provided yet, and extremely few applications even support > UIA,, we believe UIA really needs much more testing with ATVs to prove that > is ready for wide scale adoption. Microsoft's challenge will be to get > large applications, like MS Office, and ATVs to support UIA and work out > any defects.
> Now, all this said, the Vista desktop needed to be accessible so today > Vista access by screen readers is a combination of MSAA and screen > scraping. In short, access to the Vista desktop is like XP. Last year > Microsoft spent a significant effort adding the ability for screen readers > and magnifiers to capture information drawn to the desktop to reproduce > what is on XP. This capability is limited to the unmanaged environment. > Microsoft has done some mapping back to MSAA from managed code to support > basic MSAA and some text access but it is limited. Consequently, support > for unmanaged applications will depend on a client side unmanaged API > layer. Due to the limited number of managed applications there is little > business justification for ATVs to support them.
> We do believe that more work will be required for application vendors to > switch from MSAA to UIA. With IAccessible2 we complement MSAA, as is, and > we have fully tested ATV support today. Also, the effort to enable > IAccessible2 enabled applications on other platforms is significantly > smaller. We have heavily tested and designed IAccessible2 to work on an > entire office suite and with input from the Mozilla foundation. > IAccessible2 is not new in that it is derived from APIs we helped designed > for UNIX and Java and which we have been working for some time. > IAccessible2 was designed with the help of ATVs like Freedom Scientific and > GW Micro during its implementation on IBM's new office suite. Please my > blog below for more information on the Missouri project. > We are also developing next generation tooling to support IAccessible2.
> UIA has also not been designed to support ARIA and so changes to UIA may be > required to support it. Going forward IAccessible2 is an open standard and > will allow others in industry to enhance it as new technology warrants it. > Proprietary APIs are much more restrictive and this kind of participation > is very difficult. We believe they can both coexist on the same platform as > both are built on top of COM.
> The significant value add of IAccessible2, for ATVs, is we do allow them to > continue to run in process to get the performance enhancements they have > realized with MSAA. This may prove difficult with the provider/client > architecture in UIA.
> In short, we believe the two will coexist but because UIA has not been used > by major application vendors and ATVs we believe it will take some time to > be fully realized. In the meantime IAccessible2 will already have been > implemented to support large, rich, desktop applications and ARIA with full > ATV support. UIAs immediate value add will be for managed applications.
> Beyond Mozilla's planned IAccessible2 support in Firefox 3 and our > implementation in our Notes 8 productivity editors which support ODF we > will be adding support in Eclipse. That work has just kicked off. By > implementing it in Eclipse any application built using Eclipse will be able > to make use of IAccessible2 and richer access. This will ultimately allow > us to do rich model-based authoring tools in our Rational product line, and > so on. Many vendor's products work on Eclipse, ... IBM, SAP, etc.
> There are other toolkit vendors and platform vendors planning to support > IAccessible2 and I hope they will be making those announcements in the near > future.
|
