Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.
The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.
The web does have an accessibility API. It's called the DOM.
What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users and a much laggier less-featured app for users using the accessibility API, because it forces you to always have the accessibility API turned on. It forces you to treat the accessibility API as your default rendering target (and allows you to occasionally make something inaccessible by embedding a canvas element inside of that UI for one or two parts of your app.
And if you can't develop a fast app using the accessibility API, then having a toggle to turn that layer off is not really a solution for that problem. I'm very glad AccessKit exists, it's better than nothing, but that doesn't mean the apps that are using it should be proud of themselves.
Browsers seem to have resisted adding fundamental alternatives of construct-on-query accessibility trees, or some kind of “I need AT stuff” switch so you can skip setting ARIA attributes or materialising other DOM if it’s not going to be used.
The end result is that the web doesn’t properly support accessible virtualised scrolling (where you have a hundred thousand emails in a mailbox, but only render the ones on screen, still providing a meaningful scrollbar) or infinite scrolling. There’s role=feed which improves matters in most screen reader configurations, but it’s still making some compromises. But then, virtualised scrolling is imperfect even for non-AT use—things like browser find-in-page won’t work properly. Still more of the “if you want it to work properly, it has to exist in the DOM all the time” stuff.
To be honest, AccessKit itself doesn't support lazy accessibility trees for virtualized scrolling, at least not yet. It can avoid constructing the accessibility tree completely if the platform accessibility API isn't queried at all, but there isn't yet a way to only partially construct an accessibility tree while indicating that there's more available on demand. So to some extent, I guess AccessKit brings this web performance problem to native.
That being said... I have also kind of soured on virtualized scrolling over time as I've spent more time working on UX projects, and I realize that sort of sounds like an excuse (we don't support this well, but you shouldn't be doing it anyway), but... I do kind of feel like infinite scrolling and giant lists of elements to the point where the list needs to be virtualized is bad UX for most apps.
----
And to be clear, I'm not necessarily saying that the DOM is perfect as an accessibility tree, just that it's good enough compared to the kinds of accessibility APIs that most native devs want when they complain about the DOM. In practice, a full-featured accessibility API with the same feature-set as the DOM and the same level of capabilities would likely have performance costs no matter how it was implemented in the browser.
Sure it could be better. But also all of those improvements could just be added to the DOM instead of making a new native web API. The biggest difference between adding those improvements to the DOM vs reconstructing something very similar to the DOM as a separate browser API is that devs could ignore the performance costs of that API and only benchmark their apps with the accessibility API turned off.
And I think it's good for devs not to have that option (or at least, for browsers themselves not to directly provide that option; again I'm not saying that I don't think AccessKit should exist).
That being said, yeah, there are people in this very comment section saying that of course egui is accessible, it supports AccessKit. So it's not really theoretical, any attempt to close the gap with AccessKit is going to be used by people as an excuse to build inaccessible applications. That's already happening in this comment section right now.
But that doesn't mean that AccessKit shouldn't exist it's just... one of the downsides to reducing the number of entirely inaccessible apps. It's a partial fix for a bad situation, and it's good for devs to use it if they have to, but it's far better for devs not to need to use it.
AccessKit is trying to help fix a problem as best it can. My issue is with the people and frameworks that are causing the problem.
So I usually produce pngs via matplotlib and only selectively use interactive, js based, visualisations but they are get so unbelievable slow quickly when that your whole tab freezes.
For individual widgets like data visualisation, go ahead, use canvas if you want; I won’t complain—though make sure if you have any links in it that you have actual <a> links on top of the canvas for the user to interact with. And also consider if you can SVG. Anyway, individual canvases are fine; but don’t put everything in a single canvas.
Things like Google Docs and Figma are often cited as examples of how canvas-based rendering can be not bad, but neither are pure canvas: the user interface of both is full DOM, and it’s only the document area that’s canvas. (Also, I find Google Docs somewhat unpleasant: its rendering latency and throughput while you type is terrible, and keyboard caret navigation doesn’t match my platform’s behaviour in many places.)
See also https://news.ycombinator.com/item?id=33863185 (similar content to this comment).
I know Slint and egui have accessibility support.
I still keep my comment about the article -- I feel discussions of GUIs should talk about this type of thing, as so many people require accessibility support.
If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way.
[0]: I am aware of AccessKit. Where's the OS backing?
(but hopefully it'd be a temporary step back)