4 ms·

Until Wayland actually has an accesibility story, X is really the only choice. Don't think most grassroots projects will have that.

by shakna 10mo ago

torginus 10mo ago
Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events? Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.
- KetoManx64 10mo ago
  What does this matter for blind people who want to use Linux? All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.
  - torginus 10mo ago
    To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux. Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
    - shakna 10mo ago
      The standard was Extended Window Manager Hints [0]. Above X11, implemented by GTK and everyone else. Right. However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new. You can't even get the title of a window, under Wayland. That's private to that process tree. Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases. [0] https://specifications.freedesktop.org/wm/latest/ https://specifications.freedesktop.org/wm/latest/
nialv7 10mo ago
pretty sure at-spi is independent from the display server
- shakna 10mo ago
  Parts of AT-SPI are impossible to implement under Wayland. > Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland. https://news.ycombinator.com/item?id=45237411 https://news.ycombinator.com/item?id=45237411

Until Wayland actually has an accesibility story, X is really the only choice. Don't think most grassroots projects will have that.

by shakna 10mo ago

Until Wayland actually has an accesibility story, X is really the only choice. Don't think most grassroots projects will have that.

torginus 10mo ago

Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events? Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.

KetoManx64 10mo ago
What does this matter for blind people who want to use Linux? All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.
- torginus 10mo ago
  To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux. Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
  - shakna 10mo ago
    The standard was Extended Window Manager Hints [0]. Above X11, implemented by GTK and everyone else. Right. However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new. You can't even get the title of a window, under Wayland. That's private to that process tree. Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases. [0] https://specifications.freedesktop.org/wm/latest/ https://specifications.freedesktop.org/wm/latest/

nialv7 10mo ago

pretty sure at-spi is independent from the display server

shakna 10mo ago
Parts of AT-SPI are impossible to implement under Wayland. > Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland. https://news.ycombinator.com/item?id=45237411 https://news.ycombinator.com/item?id=45237411