To be clear, absolutely nothing is stopping apps from doing this in JS today. There have been multiple "canvas web frameworks", even one getting funding to the tune of $27m before imploding: http://deprecated.famous.org/

> And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem.

There will also be performance problems. The web is already slow using the heavily optimized DOM. It's going to be so much slower when things try to use a fullscreen Canvas instead. That breaks all sorts of optimization opportunities browsers currently leverage.

But sadly it'll probably happen. We'll all end up downloading forks of browsers in various states on each site we go to as each site decides to re-invent the DOM & all the rendering optimizations that go along with it.

> And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem.

I know nothing about webm beyond the idea that it's supposed to help developers write code in non-Javescript languages which can then be run in a web page via a canvas element. If my scant understanding is correct, then I assume it will be up to those developers to include code (or relevant libraries in each language) that will make the canvas element act responsively, and handle issues like accessibility, user interaction, tracking etc to give the best user experience?

My view is that current Javascript libraries that target the canvas element have largely failed to address canvas-related issues such as accessibility in a decent way - which doesn't give me much hope that future webm libraries which could be used to build user interfaces will do any better ... unless there's strong pressure to make accessibility a core goal for such libraries.

There's no good reason not to include accessibility (and user interaction, tracking etc) into any library - including JS libraries - that target the canvas element. Part of the reason for me recoding my own JS canvas library was to address exactly these issues (results of my work here[1]), and if I can manage to solve a lot of the issues then there's no reason why others library maintainers couldn't do a much better job of it than I did!

[1] - http://scrawl-v8-progress-0919.rikworks.co.uk/

"if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem"

As a web-development near illiterate, this equals to me as pages that aren't auditable before they're shown, which would pretty much translate into unblockable ads. Please someone tell me I am wrong.

Yes/no.

If you switch off javascript then the WASM files won't be able to be loaded.

Then on top of that I guess you could just filter for all `canvas` elements. That will cripple some [biased edit: worthwhile] uses at the same time, though.

A very valid concern. I wonder if it would be easier at this point to have screenreaders work visually rather than trying to dive into the source to grab the text.

Text recognition is getting pretty good nowadays afterall.

This seems like a really hard problem to me. I actually wish image formats like PNG could have annotations inside them saying "there a is 45px tall 34px wide letter 'a' at position ..." which would be automatically generated by image editing software and screenshot apps. It would make it possible to select text inside an image and allow screen readers to work better.

> there will be a major accessibility problem

The modern web already burned that bridge and loudly declared that it doesn't give two shits about accessibility. There are plenty of companies that gladly sacrifice accessibility to have "beautiful" interfaces designed by some self-important jackass.

That argument sucks. Yes there are sites with poor accessibility, but there's also a lot of sites that are fine. It would be a huge step backwards if they switched from DOM to Canvas.

I don't disagree that it'd be bad, I disagree that a lot of sites won't do it anyway.

You raised a very valid point here. How much difference will be between a canvas-painted web-app and a native Windows application? The line woll get increasingly blurry.

The "web" app will have worse performance.

You mean for accessibility? Maybe but there shouldn't be any fundamental reason why an accessibility tool can read a windows app and not web app, since under the hood Chrome and Firefox can use the same interface this tool interfaces with.

If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough for most applications to matter. Especially if those applications are written in anything other than C/C++, they'll have similar performance characteristics.

You're right, it might be only so slightly worse as to not matter, or be better than a language that is close to the metal, but with worse design.

Obviously, for such a wide prediction I can only speak theoretically...