Skip to main content

Where can I download AccExplorer32 (and other accessibility tools)? RRS feed


All replies

  • Hi, N.G.,

    The tools are available in the Windows SDK.  Here's the latest:

    You don't have to install the whole thing -- you can uncheck everything but the tools, which will make the installation much faster.

    Making the tools part of the SDK gives them a more reliable versioning situation than just hanging them out on a web site, which is why we arranged it that way.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, December 16, 2010 11:36 PM
  • Thanks for the link, Michael.

    Making the tools part of the SDK is logical, but there are still broken links on MSDN pointing to the old download location.  We can't appreciate reliable versioning if we can't find the tools.


    Monday, December 20, 2010 8:42 PM
  • That's fair.  Can you please reply with a link to the page with the broken link so that I can contact the right folks to get that cleaned up?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, December 20, 2010 11:10 PM
  • Hello Michael, I installed the SDK and still no ACCEXPLORER32, the Tools Reference help file that is installed with the SDK doesn't mention it either. About the broken link, here: , and of course all the references to the tool in the UII / CCA documentation. Was that tool retired?, thanks.
    Friday, July 27, 2012 8:03 PM
  • Hi David,

    I can't help with AccExplorer32, as I've never used that tool. There are a few tools around now which are considered legacy, and no further work on them is currently planned. AccExplorer32 might fall into that category.

    There are four tools which are commonly used these days. I use two of these all the time - Inspect and AccEvent. These tools can be downloaded with the Windows SDK. Inspect allows you to examine what accessibility data is being provided by apps. Whenever I build a UIAutomation (UIA) client app to access UI data from some other app, I always point Inspect to that provider app first. This make it easy to see what data is available, and I can then build my own app in a way that I know will achieve what I want. (Some provider apps don't expose all their data in the way you might expect.) Given that the Inspect tool uses the native-code UIA API that's available in Windows, I know my own client app can also access that data using the that API. (I only ever use the native-code UIA API that's available in Windows, rather than the managed version of the API that's part of the .NET Framework.) Inspect can report the accessible data under the mouse cursor, or focus keyboard focus, and also shows the UIA tree of elements related to all the UI shown on the screen. All this information is invaluable when developing client apps.

    The AccEvent tool reports events which are being raised by UI. (For example, FocusChanged events or PropertyChanged events.) So if your client app needs to react to something changing on the screen, you can first use AccEvent to see what events are being raised, and then have your own client app register for those events. Again AccEvent uses the native-code UIA API that's available in Windows.

    So when building client apps, often Inspect and AccEvent are the two tools you really need. The Windows team uses these tools extensively to examine the accessibility of Windows features.

    Another tool which can be helpful as part of verifying that an app you've built is accessible, is AccChecker. This can be downloaded at It can run a number of tests on your UI, and report issues which may need closer inspection. I should stress that if AccChecker doesn't report issues, then this doesn't mean the UI is fully accessible. You always want to run manual tests in addition to this. (For example, verify that all your features are accessible when you’re only using the keyboard, and check everything looks good when a high contrast theme is selected.) Sometimes AccChecker reports false positives, whereby it reports a potential problem with the UI, but in fact the UI's fine. While AccChecker is not infallible, it can be very helpful for finding some issues you'll want to address in order to make your app more accessible.

    The last tool of the four is UIAVerify, which is available at I've not used this tool myself, so I can't comment on it. It's mainly used by people developing UI frameworks, and they want to examine the accessibility of controls they're building.

    If you have questions on how Inspect or AccEvent use UIA to generate their results, let me know.



    • Proposed as answer by David Triana Sunday, July 29, 2012 3:23 AM
    Saturday, July 28, 2012 9:14 PM
  • Guy, thanks for your very complete answer, It helped me a lot, however I'm still fighting with what I'm trying to accomplish.

    I'm trying to automate a Legacy app under CCA for Dynamics CRM that uses UI Automation. The legacy app was made years ago, part VB6, part Winforms with Framework 1.1. The automation I need to do requires that when certain control within that application changes it's visible property to hidden a Dynamics CCA action starts. The control is a Pane (however it shows as Role: window). I've been unable to capture that event. Using the build in features on CCA doesn't work because it expects that the control is available to attach to it and the moment when the control is created is not predictable.

    Writing some code, creating an AutomationEventHandler for every new Window, then looking for the window that contains that control I've been able to attach another event handler to the control when it becomes available, however none of the patterns documented in MSDN for the automation api raises an event when the control goes form visible to hidden. 

    The AccEventViewer doesn't show anything when that happen either.

    Using Inspect it shows a State property that changes from focusable to invisible,focusable , however that change doesn't seem to raise any event from the UI Automation /ACCEvents point of view. I've also tried with the AddStructureChangedEventHandler pointing to the element and to it's children, no luck.

    What do you think? is there a way to make this work with UI Automation or should I consider going back to the WIN32API ?,


    Thursday, August 9, 2012 4:54 PM
  • Hi David, could I just confirm that you’ve tried the following…

    1. Get to a point where the control of interest is visible.

    2. Run AccEvent and set it up to track every type of UIA event. (This means checking a lot of checkboxes in the AccEvent Settings dlg, which is pretty tedious unfortunately.)

    2. Set AccEvent to report events from all descendants of the root element.

    3. Once AccEvent is reporting every event generated by all UI, hide your control, and then stop AccEvent from reporting events. (Go to the Events menu and select Stop Listening.)

    4. Take a look at the events generated around the time that the control disappeared, and try to determine whether any were specific to the closing of the control.

    This is the sort of thing I do whenever I need to find some event that I can use to track some specific action that's happening in the UI. I think you've probably already done that, but I just thought I'd check.



    Thursday, August 9, 2012 11:21 PM
  • Hello Guy, no, I cannot do that, the AccEvent hangs if I visit that menu under UI Automation, even after a fresh start without opening anything else. After a while Visual Studio JIT Debugger pops up showing an unhandled win32 exception occurred in AccEvent.exe .

    I also inspected the control i'm interested with UI Spy and the ControlPatterns section is empty, is that relevant?

    While watching events with the AccEvent I found another control that always shows up for the use case scenarios I'm working on, however the event it reports is a UIA:FocusEvent and the Sender ControlType shows up as Not Supported. The events listener for focus related events is only system wide and I'm afraid that can be very performance demanding, can it be the case?

    Thanks for all the time you're putting into this.

    Friday, August 10, 2012 12:36 PM
  • Hi David, it's unfortunate that an exception occurs in AccEvent in the scenario you're interested in. If there's some unexpected data being supplied to AccEvent, then as an SDK tool, it might not be as resilient to that as other products are. (I'm not familiar with UISpy, so I'm afraid I don't know what can be gleaned from the data it shows.)

    Given that the app you're working with is a legacy app, it's possible that the root cause of the problem won't be determined. So if you can accomplish what you want to achieve by reacting to a Focus change event, I think that might be the best solution. Despite focus tracking being system wide, it doesn't significantly impact performance. Assistive Technology apps might have focus tracking on all the time in order to meet the needs of their users. Even if the ControlType for the sender of the FocusChanged event isn't available, hopefully there are other properties which are usable. Perhaps the AutomationId or Name properties? (Though care must be taken if the Name is used, as that's localized and so can change.)



    Friday, August 17, 2012 4:57 PM