Accessibility considerations

Mon Mar 14 00:49:15 UTC 2016

On Fri, Mar 11, 2016 at 02:13:03PM +0800, Jonas Ådahl wrote:
> Hi,
> 
> On Fri, Mar 11, 2016 at 06:51:35AM +0100, Timofonic wrote:
> > Please consider mandatory high contrast option with custom colors. I prefer black background and green foreground, it's a lie better for Mr eyes because clear colors really tire me. 
> 
> There is no way for a compositor to enforce this, and it has been a
> design decision so far to not let Wayland become some kind of settings
> broadcaster. I'm not aware of the current situation of cross desktop
> settings system except XSettings that obviously can't be used.
> 
> > 
> > Text-To-Speech and braille devices should be very seriously very taken in consideration too, please. I know many people work degenerative vision issues that will eventually very totally blind, some of them are Linux enthusiasts. 
> 
> Yes these are very important things that we must support. Text-to-speech
> I assume could be implemented in a similar way as input methods (like
> pinyin or on-screen-keyboard). Braille keyboard support I suspect would
> be implemented in libinput or something similar, and use the same
> Wayland protocol as input methods (the text input protocol that is being
> worked on).

braille keyboards could be implemented through libinput with a keysym event
(instead of the current keycode + xkb layout approach), but I don't have
access to one and dont' have a good description yet on how it all should
look like on the lower levels of the stack.

Cheers,
   Peter

> 
> As for braille output, this is part of the screen recorder system (for
> example Orca), which currently is done without any interaction using
> Wayland.
> 
> > 
> > Let the the client side decide isn't a good option at all! Not homogeneous behavior and many lazy efforts would make accessibility broken very often. I've seen that lots of times! 
> > 
> > And please consider to involve developers having related disabilities:They would know how to implement an usable accessibility, because they use it all time and as users know what's right or wrong on many software. 
> > 
> > Thanks for all. 
> 
> 
> Jonas
> 
> > 
> > On March 10, 2016 7:43:13 PM CET, Matthias Clasen <matthias.clasen at gmail.com> 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).
> > >
> > >Wayland uses libxkbcommon to implement xkb-like keyboard handling, but
> > >as far as I know, no Wayland compositor currently implements any of
> > >the features I listed above. xwayland inherited the X server
> > >implementation and thus, X clients do get AccessX features, but
> > >Wayland clients don't. Not an ideal situation.
> > >
> > >In GNOME, we have a client-side implementation of key repeat, which
> > >has some issues that we recently worked around by introducing an extra
> > >roundtrip before synthesizing repeat presses. I recently spent an
> > >evening trying to see how far I can get in implementing AccessX
> > >client-side (see
> > >https://git.gnome.org/browse/gtk+/log/?h=matthiasc/wayland/slowkeys).
> > >The results were mixed, I would say. While I have mostly working code
> > >for all of the AccessX features, there are some limitations:
> > >
> > >- For 'true' slow keys, the modifier keys should be delayed as well.
> > >My client-side implementation does not do that, since the modifier
> > >processing happens compositor-side, and I can only delay the events
> > >that already have modifiers applied.
> > >
> > >- I did not attempt to implement the visual bell client-side; flashing
> > >the screen by mapping a fullscreen window temporarily would just be
> > >too much of a hack. More recently, Jonas added a bell request to the
> > >private gtk_shell interface between gtk+ and mutter, so we can now
> > >reuse the existing (visual and audible) bell handling code in mutter.
> > >
> > >- Handling the toggle keys client-side means that you can only enable
> > >AccessX features if a client has focus; this needs to be handled in
> > >the compositor so using one of these shortcuts can be the first thing
> > >you do after stepping up to the computer, regardless if a client has
> > >focus or not. We also loose a feature compared to the X session: under
> > >X, we show a notification asking for confirmation ("Did you mean to
> > >turn on SlowKeys?") when the toggle keys features are triggered from
> > >the keyboard, to keep users from accidentally 'breaking' their
> > >keyboard by resting their finger on the shift key. We can really send
> > >notifications from deep inside a GDK backend.
> > >
> > >- Doing this client-side implementation in GTK+ does not help one bit
> > >for SDL or Qt or E or toytoolkit clients.
> > >
> > >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.
> > >
> > >One small complication with implementing AccessX compositor-side is
> > >that we have one client that currently does it client-side: xwayland.
> > >It would need a patch to force-disable AccessX there. This is also why
> > >I think there should be project-wide agreement on whether these
> > >features belong in the compositor or not. It would be really
> > >unfortunate and bad for interoperability if we end up in a future
> > >where these features are implemented server-side in GNOME, but
> > >client-side in KDE or the other way around.
> > >
> > >For the implementation itself, I guess it really belongs into
> > >libxkbcommon, although that means it needs timers (or hooking up to a
> > >mainloop). I find it intriguing that libxkbcommon/src/state.c has this
> > >comment:
> > >
> > >/*
> > >* This is a bastardised version of xkbActions.c from the X server which
> > > * does not support, for the moment:
> > > *   - AccessX sticky/debounce/etc (will come later)
> > >...
> > >
> > >Daniel, do you still have plans in this area, or did 'later' turn out
> > >to be 'never' ?
> > >If not, any pointers for where somebody else would start digging into
> > >this ?
> > >
> > >Anyway, I'd like to hear people's thoughts about this topic.
> > >
> > >
> > >Matthias
> > >_______________________________________________
> > >wayland-devel mailing list
> > >wayland-devel at lists.freedesktop.org
> > >https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> > -- 
> > Enviado desde mi dispositivo Android con K-9 Mail. Por favor disculpa mi brevedad.
> 
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 