This is from Renaud Paquay <rpaquay@google.com> of the Google Andriod Studio team:

If I may, I also ran into a Windows specific issue that is quite difficult for me to work around: As you may know, the JavaAccessBride thread wraps all requests to AccessibleContext so that they are dispatched to the AWT/Swing thread. I found one case, however, where a call is not wrapped, with the consequence that Swing components are sometimes called directly from the JavaAccessBridge thread, which is problematic in many cases for IntelliJ/Android Studio as they don't expect that.

One particular example I found is this callstack:

	(...)at javax.swing.JList$AccessibleJList$AccessibleJListChild.getComponentAtIndex(JList.java:3229)
	at javax.swing.JList$AccessibleJList$AccessibleJListChild.getCurrentAccessibleContext(JList.java:3210)
	at javax.swing.JList$AccessibleJList$AccessibleJListChild.getAccessibleRole(JList.java:3289)
	at com.sun.java.accessibility.AccessBridge.getAccessibleStatesStringFromContext(AccessBridge.java:1492)
	at com.sun.java.accessibility.AccessBridge.runDLL(Native Method)
	at com.sun.java.accessibility.AccessBridge.access$300(AccessBridge.java:36)
	at com.sun.java.accessibility.AccessBridge$dllRunner.run(AccessBridge.java:120)
	at java.lang.Thread.run(Thread.java:745)

I think the getAccessibleStatesStringFromContext should wrap the call to getAccessibleRole. I think this should be a (somewhat) trivial fix, as, afaik, almost all the calls from java.accessibility.AccessBridge to AccessibleContext are currently already wrapped.

The reason this is difficult for me to workaround is that I would have to find a way to override all the concrete implementations of AccessibleContext.getAccessibleRole and customize them to perform the dispatch manually, which would essentially mean adding a level of hierarchy below all Swing classes and update all consumers to use these new classes.