The Microsoft MSAA API cannot provide mapping for all ARIA roles as it does not have defined roles and properties for all those defined by The ARIA specification, the Microsoft UI Automation API can. UI automation provides exposure of all WAI-ARIA roles and properties via the
Testing UI Automation AriaRole support
Testing of the
AriaRole properties support requires the Windows 7 operating system and the use of an updated inspect tool, currently only available as part of the Windows 7 SDK. Results from initial testing show that all possible ARIA role values are correctly exposed via the UI automation AriaRole property, but the stated mapping of the ARIA roles to UI automation
ControlType is incomplete. I have also re-tested MSAA role mapping taking into account roles that Microsft documented as unsupported via MSAA:
- 43 out of 51 – Of the 51 WAI-ARIA role (excluding abstract roles) values that can be mapped to MSAA: Internet explorer 8.0.7100.0 maps 43 correctly.
- 32 out of 50 – Of the 50 WAI-ARIA role (excluding abstract roles) values that can be mapped to UI automation ControlType: Internet explorer 8.0.7100.0 maps 32 correctly.
- 59 out of 59 – Of the 59 WAI-ARIA role (excluding abstract roles) values that can be mapped via UI automation AriaRole property: Internet explorer 8.0.7100.0 maps 59 correctly.
Full Test Results: Comparison of ARIA roles exposed via MSAA and UI Automation in IE8
Practical Ramifications of these Results
In theory by using the UI Automation API, assistive technology can access all the ARIA role values used in web pages viewed using Internet Explorer 8 via the
AriaRole property. Although this property can only be tested in Windows 7, the property itself should be available to Assistive Technology on Vista and XP.
I emailed Michael Curran, one of the developers of the NVDA screen reader, to pick his brains on UI automation, here is what he had to say:
Technically, the properties are available on the other operating systems, but there is no real easy way for an AT to actually get at UI Automation in general, unless running on Windows 7.
NVDA, and I’m sure many other ATs, do not make use of UI Automation in Internet Explorer, as we already access the DOM directly. And although we think its great that Microsoft is exposing this info via accessibility APIs now, the older way of getting at this info still works.
Also, I said that its pretty impossible for ATs to get at UI Automation in Vista / XP. This is true, but here is a little further detail:
- ATs written on the .net platform (since 2.0 I believe) have been able to access UI Automation through a managed API. However, very few ATs are written in .net, in particular I know of know screen readers that are.
- UIAutomationCore.dll was only introduced in Windows Vista. This is code that allows any normal win32 application to implement UI Automation in their GUI. This then means that although there may be some .net applications that expose UI Automation information running in XP, no native win32 application can expose UI Automation unless running on Windows Vista or above I believe. This does seem to mean then that I might have been wrong about saying that IE would expose UIA properties in XP, especially when IE is not a .net application I believe.
- Although the new unmanaged UI Automation client API is only available in Windows 7, it would be possible for an AT to inject “in process” and use UI Automation directly in applications such as Internet Explorer, in Windows Vista. Many ATs already inject in process to read web pages anyway, however as I previously noted, I’m not too sure on the uptake of this method as many ATs already have full access to the DOM.
As you can see, the whole UI Automation story is extremely complex, and I guess still not fully complete.
Thanks to Michael for providing such detailed information! The main point for me in relation to WAI-ARIA is that “many ATs already have full access to the DOM.” which suggests that as long as ARIA is being exposed correctly via the DOM and AT’s have access to the DOM, they can implement ARIA.