Re: [g-a-devel] Making Wayland accessible

[Piñeiro <apinheiro igalia com>]

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