4 ms·

It is an xkb and GUI toolkit matter. wayland is just passing keycodes, at best the xkb configuration if I recall properly.

by sylware 9mo ago

shakna 9mo ago
Wayland broke accessibility on Linux. All of the standards-based APIs went up in smoke, with Wayland saying "not our problem". Unless you want the compositor to execute everything in trusted shell, there needs to be a way to actually interact with the system.
- sylware 9mo ago
  I was more exposed to the destruction by the javascript web of the built-in("standard") "accessibility" (for blind people) of the noscript/basic (x)html aka classic web (or "braille terminals"). One of the powers of wayland is dynamic discovery: a GUI application has to query the compositor interfaces then features, then turn on and off stuff dynamically (for instance, the clipboard). Which "accessibility" x11 APIs you are talking about?
  - shakna 9mo ago
    Under X11, we had Extended Window Manager Hints [0]. The new protocol that is meant to work everywhere is ATK/AT-SPI. However, as mentioned in the posted proposal, AT-SPI Device can't be implemented under Wayland, right now. Under Wayland, you also can't find your mouse. [1] No input system can find out your active window, so no remapping for applications. [2] And no key rebindings, at all, yet. [3] The issue I posted that started this thread was proposed by Orca. This is not some random person saying that Wayland can't do what they need, yet. Its one of the most popular accessibility software programs available on Linux. Libinput doesn't have capability monitoring, saying instead it'll need to be implemented by the server, so it needs to be Wayland's problem, not theirs. [4] [0] https://specifications.freedesktop.org/wm/latest/ https://specifications.freedesktop.org/wm/latest/ [1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/383 https://gitlab.freedesktop.org/wayland/wayland/-/issues/383 [2] https://gitlab.freedesktop.org/wayland/wayland/-/issues/326 https://gitlab.freedesktop.org/wayland/wayland/-/issues/326 [3] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/216 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... [4] https://gitlab.freedesktop.org/libinput/libei#capability-monitoring https://gitlab.freedesktop.org/libinput/libei#capability-mon...
    - sylware 9mo ago
      Invasive complex features and the disaster of ICCCM, I do not want any GUI applications with that much power over the compositor. Then, the power of wayland has to be leveraged the right way: a set of custom and clean accessibility/instrumentation wayland protocols, queried dynamically for support or not by GUI applications which handle that complexity. A lot is now directly client side though. You will have probably to maintain a set of forked/branched compositors with this accessibility/instrumentation code, which would be deployed as an alternative only on demand.
      - shakna 9mo ago
        Cool... Wayland is how old now? 15 years? I just want to use my computer. That I'm blind should not be a "fork it and maintain it yourself, you're on your own" story. You basically just told me I shouldn't exist, for want of a different kind of keyboard.
        sylware 9mo ago
        Stop engaging in bad faith please, it is not what I said. You are asking the wrong people, ask the the AT-SPI/ATK and GUI toolkit people to design the required interfaces (leveraging the dynamicity of wayland or some other custom and simple protocols perhaps) and to devel/maintain the required complexity for those interfaces to work. Those interfaces are beyond instrusive which defeats client application isolation and compositor independance of niche complexity which is a corner stone of wayland. That's why those complex compositors (or "modules" of some huge compositors) will be on demand only (and they are highways for malware and spyware).
        shakna 9mo ago
        > ask the the AT-SPI/ATK and GUI toolkit people to design the required interfaces As I've already pointed out, multiple times, those are the people asking Wayland for the necessary protocols, so that they _can_ design the required interfaces. KDE has pretty much given up, and kwin is a fork with a ton of extensions [0]. Because Wayland always says no. Gnome does the same, as does wlroots and sway. Which means that all of them have incompatible protocols, meaning accessibility is sharded between desktop environments. Your apps, that you need just to press a key, are all incompatible with each other. Accessibility is not some niche thing. It is a cornerstone of interface design, that assists everyone who interacts with it in some way. Your view is very simple: Security trumps accessibility. That has been obvious since the first post. My view is simpler: I am allowed to exist, and so security must make considerations for accessibility. As things stand, both Windows and macOS have a better accessibility story than Linux, because of this dogged approach. [0] https://invent.kde.org/libraries/plasma-wayland-protocols/ https://invent.kde.org/libraries/plasma-wayland-protocols/

It is an xkb and GUI toolkit matter. wayland is just passing keycodes, at best the xkb configuration if I recall properly.

by sylware 9mo ago

It is an xkb and GUI toolkit matter. wayland is just passing keycodes, at best the xkb configuration if I recall properly.

shakna 9mo ago

Wayland broke accessibility on Linux. All of the standards-based APIs went up in smoke, with Wayland saying "not our problem". Unless you want the compositor to execute everything in trusted shell, there needs to be a way to actually interact with the system.

sylware 9mo ago
I was more exposed to the destruction by the javascript web of the built-in("standard") "accessibility" (for blind people) of the noscript/basic (x)html aka classic web (or "braille terminals"). One of the powers of wayland is dynamic discovery: a GUI application has to query the compositor interfaces then features, then turn on and off stuff dynamically (for instance, the clipboard). Which "accessibility" x11 APIs you are talking about?
- shakna 9mo ago
  Under X11, we had Extended Window Manager Hints [0]. The new protocol that is meant to work everywhere is ATK/AT-SPI. However, as mentioned in the posted proposal, AT-SPI Device can't be implemented under Wayland, right now. Under Wayland, you also can't find your mouse. [1] No input system can find out your active window, so no remapping for applications. [2] And no key rebindings, at all, yet. [3] The issue I posted that started this thread was proposed by Orca. This is not some random person saying that Wayland can't do what they need, yet. Its one of the most popular accessibility software programs available on Linux. Libinput doesn't have capability monitoring, saying instead it'll need to be implemented by the server, so it needs to be Wayland's problem, not theirs. [4] [0] https://specifications.freedesktop.org/wm/latest/ https://specifications.freedesktop.org/wm/latest/ [1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/383 https://gitlab.freedesktop.org/wayland/wayland/-/issues/383 [2] https://gitlab.freedesktop.org/wayland/wayland/-/issues/326 https://gitlab.freedesktop.org/wayland/wayland/-/issues/326 [3] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/216 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... [4] https://gitlab.freedesktop.org/libinput/libei#capability-monitoring https://gitlab.freedesktop.org/libinput/libei#capability-mon...
  - sylware 9mo ago
    Invasive complex features and the disaster of ICCCM, I do not want any GUI applications with that much power over the compositor. Then, the power of wayland has to be leveraged the right way: a set of custom and clean accessibility/instrumentation wayland protocols, queried dynamically for support or not by GUI applications which handle that complexity. A lot is now directly client side though. You will have probably to maintain a set of forked/branched compositors with this accessibility/instrumentation code, which would be deployed as an alternative only on demand.
    - shakna 9mo ago
      Cool... Wayland is how old now? 15 years? I just want to use my computer. That I'm blind should not be a "fork it and maintain it yourself, you're on your own" story. You basically just told me I shouldn't exist, for want of a different kind of keyboard.
      - sylware 9mo ago
        Stop engaging in bad faith please, it is not what I said. You are asking the wrong people, ask the the AT-SPI/ATK and GUI toolkit people to design the required interfaces (leveraging the dynamicity of wayland or some other custom and simple protocols perhaps) and to devel/maintain the required complexity for those interfaces to work. Those interfaces are beyond instrusive which defeats client application isolation and compositor independance of niche complexity which is a corner stone of wayland. That's why those complex compositors (or "modules" of some huge compositors) will be on demand only (and they are highways for malware and spyware).
        shakna 9mo ago
        > ask the the AT-SPI/ATK and GUI toolkit people to design the required interfaces As I've already pointed out, multiple times, those are the people asking Wayland for the necessary protocols, so that they _can_ design the required interfaces. KDE has pretty much given up, and kwin is a fork with a ton of extensions [0]. Because Wayland always says no. Gnome does the same, as does wlroots and sway. Which means that all of them have incompatible protocols, meaning accessibility is sharded between desktop environments. Your apps, that you need just to press a key, are all incompatible with each other. Accessibility is not some niche thing. It is a cornerstone of interface design, that assists everyone who interacts with it in some way. Your view is very simple: Security trumps accessibility. That has been obvious since the first post. My view is simpler: I am allowed to exist, and so security must make considerations for accessibility. As things stand, both Windows and macOS have a better accessibility story than Linux, because of this dogged approach. [0] https://invent.kde.org/libraries/plasma-wayland-protocols/ https://invent.kde.org/libraries/plasma-wayland-protocols/