Created attachment 288771 [details]
accessible event listener

Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal
2. Press and hold down Alt (or Ctrl+Alt) to get into one of the switchers
3. Press and release Tab (keeping the keys pressed in step 2 pressed)

Expected results: The accessible object:state-changed:selected event would be preceded by the window:activate for the switcher.

Actual results: The accessible object:state-changed:selected event is followed by the window:activate event:

$ ./selected.py 
[push button | ] object:state-changed:selected
[window | ] window:activate
[panel | ] object:state-changed:focused

I realize that assistive technologies like Orca need to be flexible about event ordering. And Orca for the most part is. But in this particular case, because Orca doesn't know the user is even in the switcher, it ignores the state-changed:selected event. (Apps running in the background often spew accessible events, and most of the time those events really should be ignored.)

The perfect event ordering, if possible, would be:
[window | ] window:activate
[panel | ] object:state-changed:focused
[push button | ] object:state-changed:selected

But if the last two were reversed, that should be good enough(tm), falling into the category of Orca needs to be flexible.  Having the window:activate event first so Orca knows what follows should be presented to the user would be extremely helpful. Thanks!