Ah good point, I guess my hope was that it could be a viable option for general GUI work, since everyone seems to find it really pleasant to use, and Id expect it to be easier to add accesibility features to imgui than to make eg Electron more performant.
> and Id expect it to be easier to add accesibility features to imgui than to make eg Electron more performant.
I wouldn't be so sure about that. Accessibility is difficult and very large, and would probably need major changes. Besides, I don't think Electron by itself cannot be performant. You can build pretty fast applications with it, if you know what you're doing. Most Electron developers don't focus on performance/resource usage though, but be able to ship fast. That's one of the major reasons web people chose Electron in the first place.
There's now 'accesskit' which seems to be targeted specifically at providing a cross-platform accessibility interface for custom UI frameworks (including immediate mode frameworks). It's written in Rust, but it has an optional C API. The most realistic option for Dear ImGui is probably to expose an "accessibility cmdlist" similar to how it exposes a "render cmdlist", and Dear ImGui user code can map this "accessibility cmdlist" to the tree structure AccessKit expects as input.
There are libraries that communicate with screen readers of every platform. Of course, you need to think where the text comes from and all so it scales with your app, but it really is a non issue in the end.
(edit: focusing in text having "meaning" and being spoken here. As it is very often I see this question about immediate mode GUIs. Of course there are other things about accessibility, but they're more of a design question rather than technology.)
