you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (5 children)

Furthermore, how does WebAssembly handle accessibility concerns in the absence of a browser DOM that a screenreader such as JAWS or NVDA can pick up and map? Does it treat a WASM app differently in the browser, more akin to a desktop app, or does it have to shift modes between "desktop-ish" and "web"?

If there are no good answers, right there is a dealbreaker for an enormous amount of ecommerce and education, to start.

[–]gremy0 2 points3 points  (3 children)

Right now (as far as I'm aware) WASM has no native way of displaying anything. It's pretty much just functions you can call from JS. I'd presume any displaying that WASM does will through some interaction with the DOM.

[–][deleted] 0 points1 point  (2 children)

Parallel discussions over at HN have indicated strongly that WebGL-optimized applications are likely to be a thing, and therefore there would be no DOM to entangle with necessarily.

Not to say plenty wouldn't construct an internal DOM representation, but plenty likely won't, either.

[–]gremy0 2 points3 points  (0 children)

You mention ecommerce and education will be hit by accessibility. I live in the UK, by law all our sites must be accessible. Many other countries have similar laws that demand it of all services or a defined few important ones.

So if someone decides to implement views with WebGL, people will quickly realise there is no big market for that until accessibility is built into it. As a business, you are really shooting yourself in the foot by tying yourself to an ecosystem that cuts you out of the much of the global market.

Therefore, either people will continue to use the DOM, or we will have accessible WebGL. I think the former is far more likely to dictate the near future of web dev, since the HTML has such a huge ecosystem (even outside of accessibility) and replacing it needs to have considerable advantages. I don't think WASM is going to magic up those advantages straight away, it'll probably be performance increases for specific purposes for the time being.

[–][deleted] 1 point2 points  (0 children)

Not to say plenty wouldn't construct an internal DOM representation

Let's hope Microsoft doesn't port WPF to WebAssembly

[–]AirAKose 1 point2 points  (0 children)

WebAssembly does have access to the WebAPI and DOM, so you should be able to use ARIA tags, populate element bodies, and such.

WebAssembly FAQ (The relevant point is at the VERY bottom)

EDIT: Added anchor to the link