Re: Making Wayland accessible
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/msg6.html - Warp the pointer to a certain position (see https://bugzilla.gnome.org/show_bug.cgi?id=70 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Making Wayland accessible
Hi, just replying to this part: On 15 October 2013 22:05, Matthias Clasen matthias.cla...@gmail.com wrote: - input tweaks like slow keys or bounce keys or hover-to-click naturally fit in the event dispatching in the compositor In the same spirit of having key repeat on the client side, I think that slow, bounce and sticky keys should also be implemented by the clients. Doing these on the compositor would in particular make things more complex for xwayland which (I assume) should continue to provide these features for X clients while being a regular wl_keyboard client itself. MouseKeys though, seems like it can be implemented in the wayland compositor and we should probably remove the functionality from xwayland. Hover-to-click can be done in the compositor as well. Rui ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Making Wayland accessible
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. 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) - Warp the pointer to a certain position (see https://bugzilla.gnome.org/show_bug.cgi?id=70 for a description of how this 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. 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 ? Matthias ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
