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.
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).
> 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.
"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."
Your are not making any sense at all: it is up to the AT-SPI/ATK people to design their own set of wayland interfaces related to their definition of accessibilty and to code/maintain their related software (which could be compositors, or modules of compositors). Wayland being a set of interfaces which are fully discoverable and dynamic at runtime makes all that possible.
If that was the case... Why would those same people be putting forward protocols to implement? Why do they have to fight for Wayland just to say no?
Wayland is the gutter sink here. Nobody else. Everyone else has done what they can, and continue to do what they can. Wayland has said no to the very interfaces you claim need to be implemented - they already have been.
What are you even talking about? Since wayland is purely discoverable and dynamic at runtime, you do not need the 'wayland people' to start to do anything.
I could tomorrow start to design my own set of 'wayland interfaces for spy agencies' in order to provide wayland clients a way to spy on all other applications and even on what the compositor is doing, and why not implement some super ultra giga user interactions that specific to accessibility. Then I could pick up GTK+ mutter, branch it, and start to dev the modules implementing such set of interfaces.
Since wayland is actually "x12", if starting anew, this is even a good opportunity for ATK/AT-SPI people to remove the non pertinent legacy burden, aka do some cleanup passes.
And you say those interface were already designed and implemented why are you whining about?
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.