Wayland compositors and accessibility
samuel.thibault at ens-lyon.org
Tue Apr 16 15:22:32 UTC 2019
Simon Ser, le lun. 15 avril 2019 19:23:51 +0000, a ecrit:
> On Wednesday, April 3, 2019 4:00 PM, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> > Olivier Fourdan, le mer. 03 avril 2019 14:39:29 +0200, a ecrit:
> > > > What we currently have in Wayland is support for AccessX, directly
> > > > implemented in mutter. The rest of accessibility features are currently
> > > > mostly broken.
> > >
> > > Well, instead of "mostly broken", I'd say it's a WIP on the GNOME
> > > side. To recap the state of the accessibility features in GNOME:
> > Some of these cover what I mentioned indeed, but that does not cover the
> > Orca needs for instance, and is GNOME-only. I'd really not push for a
> > GNOME-only solution that would only leave disabled people with one
> > choice of desktop, and not be able to use other people's computer which
> > may not be running GNOME.
> Do you have a list of accessibility features you'd like to have and a
> description of what they do, how they look like?
That was the start of the thread:
This is diverse, and of course this is not thorough: nature is inventive
in the kind of disabilities that people may have, and thus the kind of
compensation we might have to think of.
> > > > It could also provide interfaces for plugging accessibility
> > > > features implemented in separate processus (e.g. screen reader). To
> > > > avoid keyloggers and such, such interface needs to be available only to
> > > > trusted accessibility processes.
> > >
> > > That does not need to be Wayland protocols though, these could be DBUS.
> > Sure.
> A few things to keep in mind:
> - If your feature needs to be strongly tied to Wayland (e.g. it needs
> to display a surface), Wayland protocols would probably be better
> - Some compositors don't have D-Bus interfaces (e.g. KDE, Sway).
> > > But I guess we need to define what a "trusted accessibility processes"
> > > is and how the compositor can enforce that.
> > Yes. AIUI there were already some discussions about this on
> > wayland-devel?
> There were some discussions about security, yes. As of now the
> consensus mostly is: if the compositor starts the client, then it can
> provide access to privileged interfaces.
Ok. So since the compositor is under the user's responsibility we can
make it start what we want.
One thing that we often need to do however is to start a screen reader
instance by hand for development/debugging/etc. but I guess we could
introduce ways to force access in that case.
More information about the wayland-devel