Created attachment 237135 [details]
test script

Steps to reproduce:
1. Launch the attached test script
2. Launch gtk3-demo
3. Arrow Up and Down in the list of demos

Expected results: There would not be an excessive amount of accessible text events each time the selection changed.

Actual results: Arrowing Up or Down **just once** results in hundreds -- and in some cases thousands of accessible text events:

  KEY PRESS: Down
    220 object:text-changed:insert events
    220 object:text-caret-moved events
      2 object:text-changed:delete events
  KEY RELEASE: Down

  KEY PRESS: Down
   1179 object:text-changed:insert events   <-- !!!
   1179 object:text-caret-moved events      <-- !!!
      2 object:text-changed:delete events
  KEY RELEASE: Down

  KEY PRESS: Down
    585 object:text-changed:insert events
    585 object:text-caret-moved events
      2 object:text-changed:delete events
  KEY RELEASE: Down

  KEY PRESS: Down
    232 object:text-changed:insert events
    232 object:text-caret-moved events
      2 object:text-changed:delete events
  KEY RELEASE: Down

Many of these events are from the text widget in the GtkNotebook whose text is not visible (i.e. to the sighted user, because it's on the notebook page which is not active). And even if the notebook page were visible, this many text events seems less than ideal. One, single big ol' text event should suffice.

And, yes, I realize that gtk3-demo is not a typical end-user app. But assuming it does not have its own custom accessibility implementation, it is theoretically possible that a real end-user app could spew a similar amount.