Accessibility considerations

[Peter Hutterer]

On Thu, Mar 10, 2016 at 01:43:13PM -0500, Matthias Clasen wrote:
> Hi,
> 
> I would like to discuss strategies for implementing accessibility
> features in Wayland that will be needed for a fully featured desktop.
> There's a whole list of individual items, but for now I'd like to
> focus on keyboard accessibility features, ie roughly the feature that
> traditionally labeled AccessX:
> 
> - slow keys (only accept key presses after a delay)
> - sticky keys (support one-key-at-a-time operation by latching and
> locking modifiers)
> - bounce keys (reject quick key presses of the same key)
> - toggle keys (special key bindings to enable the aforementioned
> features: hold-shift-for-8-seconds for slow keys,
> shift-5-times-in-a-row for sticky keys)
> 
> The following two are not technically AccessX, but are close enough to
> include them:
> - key repeat
> - visual bell (all of the AccessX features have configurable bells;
> the visual bell can be configured to be per-window or global)
> 
> Under X, all of these features are implemented in the XKB code in the
> server (the visual bell gets handled by a client that selects for for
> XkbBellNotify. In GNOME, that is mutter).

[...]

> I know that one of the guiding principles of the Wayland architecure
> is 'client-side', but I think the limitations listed
> here are significant enough to argue for a compositor side
> implementation of keyboard a11y. I don't think that this needs (a lot
> of) new protocol, except for maybe a way to query and monitor state
> related to these features.

[...]
 
> Anyway, I'd like to hear people's thoughts about this topic.

fwiw, I fully agree that this need to be implemented on the compositor side.
Client-side first is a nice principle for things that are client-specific
but I see accessibility as a feature of the user, not of the software. Thus
it falls into the same category as other user-specific features like tapping
that are already implemented in the compositor (or even hidden inside
libinput).

Cheers,
   Peter