While tst_QAccessibility usually passes on both, xcb and wayland when no assistive technology is running, it failed consistently in a KDE Plasma Dev Wayland session when either Accerciser or the Orca screen reader are running when the test is started, with failures like this one: 1: FAIL! : tst_QAccessibility::lineEditTest() 'QTestAccessibility::containsEvent(&insertE)' returned FALSE. () 1: Loc: [.../qt5/qtbase/tests/auto/other/qaccessibility/tst_qaccessibility.cpp(2357)] 1: QWARN : tst_QAccessibility::lineEditTest() 4 accessibility event(s) were not handled in testfunction 'lineEditTest': 1: QWARN : tst_QAccessibility::lineEditTest() 1: Object: 0x0 Event: 'TextCaretMoved' Child: -1 1: QWARN : tst_QAccessibility::lineEditTest() 2: Object: 0x0 Event: 'ObjectHide' Child: -1 1: QWARN : tst_QAccessibility::lineEditTest() 3: Object: 0x0 Event: 'ObjectHide' Child: -1 1: QWARN : tst_QAccessibility::lineEditTest() 4: Object: 0x0 Event: 'ObjectHide' Child: -1 Fix that by ensuring that the key events have been processed in the widget (by waiting for the current text or caret/cursor position to match the expected outcome) before checking that a corresponding accessibility event has been sent. (It's not 100% clear to me whether the previous failure is related to the way that assistive technology/libatspi intercepts keyboard events or whether it is just some timing issue.) This makes tst_QAccessibility pass at least with QT_QPA_PLATFORM=xcb when either Orca or Accerciser are running. (With QT_QPA_PLATFORM=wayland, other test failures are still seen when AT is active while running the test.) Change-Id: Ib8fa036dc78082ddf1a0197189b0d13ef0bce9db Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>