can you tell me when use UIA Verify and when use UI Accessibility Checker ;the difference of them;can I test Manual image(no Microsoft components) by them.
Dec 8, 2008 at 7:48 PM
AccChecker and UIA Verify test different APIs in different ways. AccChecker is intended to test entire UI surface for MSAA (Microsoft Active Accessibility) compliance, and some additional accessibility
requirements, such as keyboard navigation by tabbing and unique accelerator keys. UIA Verify is intended to verify custom implementations of individual controls (for example a custom slider).
As such, you would use AccChecker when you want to test an entire UI surface (e.g. a dialog, a Control Panel applet, or the window of a game) – just point AccChecker at the window and run the verifications.
Think of AccChecker as your first line of defense – if there are no errors, you should continue with additional testing. However, if there are errors, you need to investigate them and fix them (or suppress them if you believe they are not relevant) before
proceeding with more testing. Note that even if the controls implemented UI Automation (UIA) rather than MSAA, the UIA to MSAA bridge on Windows Vista and Windows 7 will convert a subset of UIA properties to MSAA properties, so the tests would be valid.
You would use UIA Verify when you want to test individually each control which implements the UI Automation APIs. This may be helpful in two cases – first when you implement yourself a custom
control with UIA and want to make sure you have correctly implemented the programmatic access. Second, when you implement a UI surface (e.g. a dialog or application) with controls that internally implement UIA, you could still benefit from UIA Verify to make
sure that you have set up the controls correctly (for example the controls have an accessible name). Again, both Windows Vista and Windows 7 include an MSAA to UIA bridge, so you can test individual controls in a UI that uses controls that implement MSAA.
Be aware, however, that neither tools will give you 100% coverage for the accessibility testing for the programmatic access. For example, a custom control may not implement any aspect of MSAA
or UIA, in which case neither of the tools will realize that the control is there, and hence will not report a problem. You should be able to discover those controls by comparing the output of the AccChecker’s “screen reader” and discover that what appeared
visually on the UI surface is different from what the “screen reader” reported. I am just giving this example so that I don’t create the impression that testing with AccChecker and/or UIA Verify will give you the complete testing required for an accessible
product. These are just tools that can improve your testing and your efficiency, but you will need additional work as well.
Hope this helps.
AccChecker Program Manager