At a high level some of these gaps are:
- access to text
- access to tables
- role and state implementation restrictions due to integer sizes
- some reduction in enablement by the author
- use for automated testing
Microsoft's challenge will be to move people to it. Today, accessible Windows applications are based on the use of a plethora of API and reverse engineering mechanisms. These consist of: MSAA; Proprietary COM access to an applications Document Object Model (MS Office, Corel, IE, etc.); the Java Access Bridge; graphics engine hooking to access to text, carets, and selected information, and more.
In the near term Microsoft is working to map MSAA to a single UIA API layer but due to problems with MSAA's specification implementations may vary and the end result will be that this will be unrealistic. At the moment access to UIA by an assistive technology is through managed code. This requires AT vendors to rewrite from scratch or integrate a managed extension to their assistive technology. Access to legacy applications by an assistive technology will result in a performance hit. ATs will have to communicate from a managed application across boundaries to legacy applications resulting in slower access. A positive step forward would be for Microsoft to release an unmanaged client API version for assistive technologies. Like any mature company Microsoft will be forced to support their legacy infrastructure or risk breaking the accessibility of existing applications. In short, this will be a long process.
While a significant step forward for Microsoft, there are some rather significant gaps in UIA that need to be addressed:
- Performance: The performance problem will be a real barrier to implementation on large documents where large amounts of information must be cached and processed by screen readers. To address this for Linux, IBM is working with the Free Standards Group to extend the accessibility API to support large documents defined as the collection interfaces. These interfaces run in the ATK bridging layer without additional work by the application developer.
- Device Independence: Support for multiple actions for device independence. These are provided in the Java Accessibility API as far back as 1998 and are now in the Linux GAP architecture.
- Support for relationships: This also was provided in Java and now in GAP. These are essential for diagrams, flow charts, groupings, etc.
One of the things that would have given UIA more traction would have been to get UIA into the open source community to get more backing as a cross-platform accessibility API where we would focus on a Linux implementation. I had originally suggested this to their director earlier this year and he expressed interest resulting in this public commitment. Unfortunately, industry has yet to see a license agreement to review after months of waiting and we were forced to move on to alternatives.