Hi Matthias, thanks for starting the discussion. I will add some points below.
On 10/15/2013 10:05 PM, Matthias Clasen wrote: > 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. FWIW, most of the stuff we did on the recent Montreal Summit was related with Wayland. You can find a summary on this wiki page: https://wiki.gnome.org/Accessibility/Hackfests/Montreal2013 > > Most a11y features will probably end up being implemented in the > compositor: > > - input tweaks like slow keys or bounce keys or hover-to-click > naturally fit in the event dispatching in the compositor > > - display changes like zoom or color adjustments are already handled > in gnome-shell under X > > - the text protocol should be sufficient to make on-screen keyboards > and similar tools work > > 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: > > - Identify the surface that is currently under the pointer (and the > corresponding application that is registered as an accessible client) FWIW2, there is a running conversation about that here: https://mail.gnome.org/archives/gnome-accessibility-devel/2013-October/msg00006.html > > - Warp the pointer to a certain position (see > https://bugzilla.gnome.org/show_bug.cgi?id=709999 for a description of > how this is used) Also tracking mouse position (More about that here, https://bugzilla.gnome.org/show_bug.cgi?id=710012, although it doesn't include a description about how it is used). > > - 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 > > All of these features violate the careful separation between clients > that Wayland maintains, so that probably calls for some privileged > interface for ATs. Most of the people I asked (mostly after Wayland related presentations on GUADEC and others) pointed to that direction. > I would appreciate feedback and discussion on this. > > Has anybody else thought about these problems already ? > > Are there better ways to do these things under Wayland ? > BR -- ---- Alejandro Piñeiro _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
