|
|
|
|
|
|
by mwcampbell
1385 days ago
|
|
|
> I feel like I should preemptively apologize You should not. A mentor once told me that we disabled people tend to apologize too much. You are right to point out the problem of accessibility in this context, despite the negative responses you've received. Of all the GUI toolkits with wasm ports, IMO wx is the most amenable to using native HTML controls rather than doing everything with canvas. I'm sure that kind of port would take more work though. |
|
|
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