Accessibility and the graphics stack

Posted Oct 23, 2014 9:28 UTC (Thu) by daniels (subscriber, #16193)
In reply to: Accessibility and the graphics stack by nim-nim
Parent article: Accessibility and the graphics stack

a) Neither X11 nor Wayland have any notion of a UI locale. All they provide is keyboards with a specified mapping; that's it.

b) Wayland does offer a keysym-based interface which is entirely usable by specialist input methods (e.g. Maalit has been ported for a couple of years), and at no point requires decomposition to keycodes. This is something which would be perfectly usable by a braille input method, today, without any changes. The only reason the keycode-based interface also exists is because you can't handle shortcuts otherwise.

c) Wayland and X11 share the XKB _dataset_ (and not protocol) for keymaps and layout handling. Everything else was done from scratch.

d) The reason for the offset-by-8 is that the minimum valid keycode in X11 is 8, whereas it's 0 with evdev. So we just blindly add 8 to the keycode mapping; something which survived into Wayland because the dataset already reflected that.

Accessibility and the graphics stack

Posted Oct 23, 2014 16:02 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (4 responses)

We agree that a) is the only thing available in GUI. UI is locale is available from lower in the stack. However since it is *not* what apps need it is a problem.

What apps want is :
1. the locale of the text which is being written (to apply spellcheck and other locale-specific processing), ie the language toolbar MS deployed for office then generalized in the 90's
2. what hardware key combos are free to use for keyboard shortcuts (and how they are labelled/where they are located so they can show something in config settings)

Since the only thing they can get is a) they try to infer the rest from it which can not work reliably since a) is not designed for that.

Accessibility and the graphics stack

Posted Oct 23, 2014 16:32 UTC (Thu) by daniels (subscriber, #16193) [Link]

Again, shortcut handling belongs at a higher level than raw keyboard layout handling. This has to account for things like negotiation between global and local shortcuts (e.g. when the media keys such as Play are pressed, who handles it? if the foreground application, then use that, else try to find a backgrounded media player?).

The shortcut handling itself is also intensely difficult - for instance, when you have mixed layouts such as Russian and US, you want to base the shortcuts on the US layout, but then you can throw in mixed Dvorak/US for fun.

It's not that this isn't supported, but just that it's the wrong level to support it. The kernel doesn't deal with keymaps at all and just forwards on keycodes at all; the window system doesn't, at its lowest/fundamental level, deal with shortcuts or locales either.

Nothing in Wayland precludes this from being built on top, at all; in fact, it was designed with the explicit intent of being able to do so.

Accessibility and the graphics stack

Posted Oct 30, 2014 16:50 UTC (Thu) by arielb1@mail.tau.ac.il (guest, #94131) [Link] (2 responses)

Wayland is not in the business of handling locale settings (whether the dictionary should be French or French-Canadian). It does provide keymaps, which translate physical keyboard buttons to the symbols printed on them.

Accessibility and the graphics stack

Posted Oct 30, 2014 21:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> the symbols printed on them

Guess I'm screwed[1] then, huh? :P

[1]http://cdn.shopify.com/s/files/1/0152/0433/products/Top_V...

Accessibility and the graphics stack

Posted Nov 2, 2014 15:41 UTC (Sun) by nix (subscriber, #2304) [Link]

No, no, you just get a whole bunch of XK_space out the other end!