Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.15.7, 6.7.0 RC2
-
None
-
Fedora 40.
Description
Steps to reproduce:
1. Launch any Qt app with a lot of different types of widgets
2. Use the Accerciser accessibility inspector to inspect the "Action" interface of the widgets
Expected results: All widgets would expose a "click" action (other names, e.g. "press" for buttons, would be fine too, as long as the name clearly shows that performing the accessible action is the equivalent of clicking on the widget with the mouse)
Actual results: Many widgets do not expose a "click" action (or the equivalent).
Impact: When an application is not fully keyboard accessible, users of the Orca screen reader try to synthesize a mouse click via Orca on a desired widget. Here's how that works:
1. Before trying to synthesize an actual click, Orca looks at the AtspiAction interface for an action that seems like it corresponds to click. Those action names are:
- "click"
- "press"
- "open"
- "jump" (what web browsers expose on links).
2. If Orca finds one of the above, it calls atspi_action_do_action on that item. "Click" performed.
3. Otherwise Orca tries to synthesize an actual click.
I'm the Orca maintainer. And due to changes related to Wayland, synthesizing clicks - which has always been a hack/workaround - is currently even less reliable than it used to be. We plan to get that addressed in AT-SPI2, Wayland compositors, etc. HOWEVER, that hack/workaround would not be needed if Qt provided a "click" AtspiAction which, when invoked, would trigger the same behavior that clicking with the actual mouse triggers.
Thanks in advance for considering this!