| I've seen this discussion happen before and the same problem be pointed out re: WASM and canvas[1]. (I'm sure there are more examples than just that.) The trouble is that Canvas exists for a good reason: It is much more time-intensive to re-implement something like Audacity in the DOM than it is to render Audacity to a canvas. So if we wanted to spend the time, could we be over-focusing on "just manipulate the DOM" as a solution? WASM conceives of the web browser as the "OS", or at least as hardware, and JavaScript as a means to manipulate that "hardware" (ask the browser to do things). Most operating systems expose APIs that let you do accessible things (read the screen, automate UI actions, etc.). Then frameworks like QT, for example, hook into those APIs from their own code to provide generic accessibility regardless of OS.[2] So, maybe one half of the solution here is that to try to develop a neutral API WASM can use to emit accessibility information which can then be read by JavaScript running in the browser, and transformed into objects in the DOM? Then you could write an interface to that from your framework (something like QT would be a better starting point than wxWidgets, though, admittedly) and you'd get what you need. Not that any of that is easy. But it would be fun, and naively, seems not too much harder than "rewrite app X in WASM to use the DOM" for much broader impact. Maybe this discussion already happened and there are very good reasons not to do this - but I couldn't find anything about it in previous arguments. [1] https://news.ycombinator.com/item?id=17349170
[2] https://doc.qt.io/qt-6/accessible.html |