> This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility

I'm going to tentatively push back on this, my (very limited) understanding of the at-spi protocol is that it exposes application-specific controls and that it's not relevant to conversations about how to control a DE, and that current DEs do not in fact expose a common shared protocol across all of them for the kinds of controls that Talon needs.

I'm not an expert on this stuff by any means, but from what I can tell, OP is correct and is not spouting untrue rumors. I'd welcome correction in the form of some kind of accessible documentation for integrating with those window managers that uses a universal common protocol for all of them, but getting back to something I've pointed out multiple times above:

> so excuse everyone who thinks the complaints are likely misguided. [...] This is not rocket science...

This kind of response isn't particularly convincing given that I note you still haven't linked over some novice-accessible documentation about how to work with this stuff or test it, likely because that novice-accessible documentation is difficult to find if it exists at all.

I would love some easy ways to verify what at-spi controls, how to integrate with it in different languages, and how different DEs handle exposing it for their own interfaces. The absence of approachable documentation is a big reason why people are confused about Wayland (and about other good projects like Flatpak that get commonly maligned on HN, but that's a longer conversation). The absence of easy, clear information about how all of this stuff works might at least partially explain why application developers aren't quickly modernizing.

If you think that Talon developers are lying about how DEs work, then education efforts using clear, user-and-developer facing documentation about the protocols involved would be a pretty good way of combating FUD.

----

> Right now XWayland works as it should. So provide some specifics or get off the pot...

First, as others have mentioned, XWayland is insufficient for the kinds of needs that Talon has; operations like enumerating windows or handling focus can not (and should not) be handled via XWayland unless you plan to run your entire desktop environment in XWayland.

Secondly, XWayland is not the future. It is also a dead end. I'm glad that it exists for now, it is absolutely critical for early adoption of Wayland and is critical for supporting some apps. But XWayland is not a permanent solution to accessibility problems and it's wild to hear people simultaneously say that X11 is a walking zombie and to tell people that accessibility is fine because if there are any problems with Wayland you can always just tie your applications to a walking zombie.

The goal here is to get rid of X11, or at least that's what I think the goal should be, because I do think that X11 is a walking zombie and I resent the fact that I'm still using it.

----

My concern is not that Wayland can't be accessible or that there aren't ways to make it accessible. My concern is that regardless of whether or not universal protocols exist right now, it doesn't look like they're being used and it doesn't look like Wayland is going to be accessible for a lot of people in reality. And I don't care who's fault that is; it's still the case that calling developers lazy and accusing people who are sharing real accessibility problems that they have right now of spreading "untrue rumors" does not seem to be helping to improve the situation.

This isn't a situation like NVIDIA where there's one specific company we can all shame; if a bunch of disparate developers aren't taking the necessary steps to update their applications, then something is going wrong in the communication process or the steps aren't clear enough, or the incentives aren't aligned.

Again, I would welcome clear and accessible documentation that average developers could use that demonstrates how Talon could be made to work with Wayland and how the concerns its developers have (https://github.com/splondike/wayland-accessibility-notes/blo...) could be handled.