[Accessibility] Need to be able to register for key events globally
michael at taschenorakel.de
Tue Dec 17 12:12:36 PST 2013
On Tue, 2013-12-17 at 11:23 +0100, Piñeiro wrote:
> Well, if we can consider an on-screen keyboard, or a screen reader
> trusted clients, but we can't consider as a trusted client the daemon
> providing accessibility services, then we have a problem.
A bridge to connect existing accessibility services with Wayland is the
logical first step. But I wouldn't stop there.
> In any case, my conclusion from these two emails is that in order to get
> those features we would need to define some wayland extensions, no
> matters if is Orca or at-spi2 the one using it.
> So with all that in mind, what about a plan like this:
> a) Start to write accessibility-specific wayland extensions
> a.1) Start to implement them on a compositors (first on Weston?)
> b) Meanwhile investigate if it is possible to add security policies on
> at-spi2, so this can be the trusted client using those extensions.
> b.1) If that fails, Orca would be the trusted client using those
I'd use the opportunity and design accessibility for the layer below UI
toolkits instead of adding it on top. UI toolkits that adopt Wayland
will also adopt common and useful extensions.
Being able to design the Wayland input method protocol with transaction
semantics in mind helped to create a more robust solution when compared
to traditional input contexts. Accessibility is a great deal more
complex. Better protocol semantics could improve usability in the long
For instance, one could make Wayland clients announce
accessibility-relevant objects (and their properties) to the compositor
instead of having to rely on introspecting client objects.
Yes this will break stuff but Wayland already made that decision.
More information about the wayland-devel