While that may be true, I'd suggest that it is not a consensus view and, more specifically, there is probably a consensus that the capability to do arbitrary scrapes and inputs needs to exist in a controlled fashion. Wayland had a bizarre stillbirth where the core team resisted screenshots, I can't remember when the Wayland ecosystem started getting serious about enabling screen sharing but I've got a memory that it was post-COVID.
It goes to show how challenging the space is that Wayland managed to keep trudging on, but it was nothing to do with "woke" and a lot to do with "I don't accept that screenshots are a significant development hurdle". I still flat out don't trust them to have resolved all the issues crippling things like autoclickers but I'm hopeful I'm just very out of date. The initial take was poorly designed and that bit Wayland's adoption hard.
The ecosystem may eventually reach the level of capability that X had in a standardised and secure way. Maybe it even has (I doubt it). But there is no consensus that security trumps having a usable desktop. I'm happy with an insecure desktop, anyone serious who wants to spy on me can use my phone. It is wildly insecure as far as I care and I carry it with me most hours. People trade this stuff off for convenience. Every time I've tried Wayland I discovered it had been secured against me using my system to get things done.
The security model changed drastically, and with them how those features are presented. For example Windows, being developed to the threat model of the early 90s with some stuff tacked on in the aughts, has powerful APIs for reading window content in a structured way, for getting screenshots and for injecting arbitrary inputs, and only has some tacked-on protections that protect higher-privileged processes from lower-privileged ones (e.g. task manager runs with admin privileges, and you can't inject inputs into it or read mouse events of a cursor over it unless you run with the same or higher privileges). Android was built to the threat model of the aughts with additions in the 2010s and 2020s and has great APIs for reading window contents in a structured way, getting screen content, adding overlays and injecting inputs, but they are gated behind strong capability-based permission systems, review in the most common app distribution system (play store) and require the human to jump through various hoops to confirm this is really their intent. iOS ... restricts a lot of that to Apple, because they don't trust app developers.
X.Org does all of that with a permission model similar to that of Windows NT4, without the added restrictions Microsoft added later. That is the misfeature. Wayland looked at that, looked at the ability to make something better in the somewhat disjointed linux/*nix ecosystem and decided to just not have those features rather than have a good security/permission model
As a result, generally the answer to 'how do I do X in wayland' is 'you don't. here's how you do it in KDE, here's the extension you need to install in GNOME to be able to do it, and you're rolling the dice on any other DE'. And that's as a developer, if you're a user there's a good chance the developer has gone 'fuck it, I'm sticking with X11'.
(This fragmentation is even worse when it comes to configuration. e.g. for something like graphics tablets, where there is a relatively complex configuration of how the features on the hardware map to delivered input events, it's left up the the compositor to handle how that's configured. Which means that there's basically no standard way for you to configure your tablet, and there's no complete option: you are either forced into GNOME or KDE because you need some option one supports and the other doesn't, and if you're on a smaller one, you have basically no chance. X11's architecture meant this tended to be much more standardised, and while each DE had its own UI for configuring an input device, you could in practice always fall back to another tool, even if it was usually an arcance CLI, to get what you want.)
Gnome probably attempts to restrict taking a screenshot without flashing the screen (and I'm currently trying to figure out how to bypass the restriction).
And yeah, nothing in it was related to "woke" (that's just certain dev's personal weirdness), and a lot was related to really weird community situation that X.Org (which is not X11 itself) got itself in, like the costly and failed switch to autotools (they switched, but didn't get the results they undertook that pain for). Meanwhile they were operating from "lowest common denominator" code base that got extended a lot but never truly redone (compare Xsgi, which was a compositing X server and made extensive use of multiple visuals to ensure optimal resource usage).
But, if an ecosystem that excludes people through no fault of their own grows up, that sucks.
Using a11y APIs for an app’s tests exercises both the app and its a11y. Apparently Apple does some of its automated testing this way.
Yes, the test suite must be created and run regularly. So there is a non zero dev effort and ongoing cloud resources. But once in place it’s win win.
Perhaps open source culture could follow in Apple’s footsteps?
Does it? Because last I checked, Wayland did not, in fact, have the same features, and you don't get credit for "permitting" use of something that doesn't exist.
> When you read anything about Linux accessibility, ask yourself whether you're reading something written by either a user of the accessibility features, or a developer of them. If they're neither, ask yourself why they actually care and what they're doing to make the future better.
Okay: AFAIK, mjg59 is not a user of a11y features, and is not a developer of them (22 years ago yes, since then no). Ergo, by his own standards he isn't allowed to talk about this.
