DOM access to WebAssembly will come.
https://github.com/WebAssembly/design/labels/Phase%201%3A%20...
Even if it did, you'd still lose a lot of productivity with it if you're used to working with the high level of abstraction of the DOM, e.g. line wrapping.
There are certainly cases where dropping to GLSL is the only way to get a UI to work at all, but most of the time the metadata-providing feature of HTML is far more important than squeezing some milliseconds of performance.
They did not care with Flash, neither they will care now.
Just wait until we get Flash like tooling for WebAssembly.
Besides, I said _WebGL as an alternative to the DOM_. Of course a complex visualization that can't be properly described with text will not care about supporting jaws (even though it might have gotten some free accessibility out of the box with Flash). If you rely on the DOM like most people do, there's a huge chance that you care about your text being machine-readable. Accessibility is just one of the showstoppers for generalized WebGL adoption. SEO is another.
I think some people severely underestimate the barrier of entry that WebGL/wasm needs to overcome to displace Javascript/DOM as general purpose tools.
WebAssembly is not much faster than JS, harder to develop and debug, and requires even more extra tooling.
It’s a useful technology but it’s never going to be the primary choice for application development on the web - merely a tool in the toolbox.
So expect the comeback of Flash, Silverlight, Applets, ActiveX, ....
What to do a Flash like game without anything related to JavaScript?
Pure C, C++, Rust with SDL, Unreal, Unity, ....
Miss Silverlight? Check Blazor with Ooui bindigs for Xamarin.Forms.
Go devs already have their design document for WebAssembly runtime ("WebAssembly architecture for Go").
Qt already has a prototype for WebAssembly, with improvements planned on 2018's roadmap.
And many other projects are ongoing.
The pandora box is open, the only back is if the browser vendors stop developing WebAssembly.