Hi, 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 > extensions > > Thoughts? 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 term. 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. ciao Michael _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
