<div dir="ltr"><div>As part of the ongoing GNOME Wayland porting effort, the GNOME accessibility (a11y) team has been looking into what it would take to make our existing a11y tools (ATs) and infrastructure work under Wayland.<br>
<br>Most a11y features will probably end up being implemented in the compositor: <br> <br>- input tweaks like slow keys or bounce keys or hover-to-click naturally fit in the event dispatching in the compositor<br><br>- display changes like zoom or color adjustments are already handled in gnome-shell under X<br>
<br>- the text protocol should be sufficient to make on-screen keyboards and similar tools  work<br><br>The remaining AT of concern is orca, our screen reader, which does not easily fit into the compositor. Here are some examples of the kinds of things orca needs to do to support its users:<br>
<br></div><div>- Identify the surface that is currently under the pointer (and the corresponding application that is registered as an accessible client)<br><br></div><div>- Warp the pointer to a certain position (see <a href="https://bugzilla.gnome.org/show_bug.cgi?id=709999">https://bugzilla.gnome.org/show_bug.cgi?id=709999</a> for a description of how this is used)<br>
<br></div><div>- Filter out certain key events and use them for navigation purposes. This is currently done by capturing key events client-side and sending them out again via at-spi, which will probably continue to work, even if it is awkward and toolkit authors would really like to get rid of it<br>
<br></div><div>All of these features violate the careful separation between clients that Wayland maintains, so that probably calls for some privileged interface for ATs. I would appreciate feedback and discussion on this.<br>
<br>Has anybody else thought about these problems already ? <br><br></div><div>Are there better ways to do these things under Wayland ?<br><br><br></div><div>Matthias<br></div></div>