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.
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.
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.
> 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.