Not only are they a decade late while everyone expected WASM to liberate us from JS, and it ended up being a useless toy in JS whose improvements would have been crushed by having to send all progress to JS to apply it, but then giving it access to DOM is also something you'll realize wasn't enough a decade later. Flutter doesn't need DOM; it has all of its own engine. The browser should give the whole viewpoint to the WASM so that apps can directly implement their own GUIs. And then there will be an app revolution. You can directly port your GUI to the web and have it work. No more your GUI as a WASM worker that has to have its frames painted by JS on a canvas; direct painting. You could have wxWidgets, GTK, Flutter, ... all working insanely fast, insanely beautiful. And then people can do amazing things. Imagine a web alternative that is powered by maestro Knuth's TeX; imagine operating systems as web pages, imagine alternative layout systems that do not have to rely on Web events and frame timing. That is all if the browser allows for WASM to bypass the web part and do it itself.
Basically this has been the only way to stop anything from happening. But major systems all have accessibility like web and if someone wants to support accessibility they will do it there. Those who don't, won't even do it on web. If something like I say happens, not only accessibility will be lost, but so much more will be lost too. But then if you need it you'll either implement it or use web. Figma, SketchUp, and Google Docs have their software rendered on a canvas. For them this would have made things much faster. It is giving people options. Personally I hate web. It is horrible to write software by manipulating DOM and having to work with CSS. Every time I touch html/js/css I think why can't it be a nice system? Why I have no control over rendering? At least I would have loved to have an alternative the whole web and dom, and would have killed for writing web pages like a flutter app.
You can't pin requirements on other people who don't have them. If someone doesn't have a requirement to make an accessible product, it's unlikely to be accessible.
Not at all. Before the use of TypeScript exploded, they had two features brought into it from C# which were namespaces and enums (both of which are amazingly good features. For the first one, no one knew what was the right choice back then. We had almost a dozen different module systems and TypeScript had gone their way to support all of them and namespaces were their own solution to the mess (remember they were trying to solve their own problems at first, it wasn't to dominate anything). I personally used namespaces and I could have only the TypeScript compiler running and producing a single JS file for rapid development without the burden of --- then very slow --- webpack.
And for enums, using strings as enums was not a very efficient idea. I think JavaScript introduced Symbols for locked/hidden properties but also meant to use them as enums. It never worked either and then the sum type, union type feature of TypeScript made the whole community to keep using strings as enums. This is still a very bad idea, it is not ergonomic, it is prone to many problems, and very inefficient to compare strings instead of integers. But hey TypeScript tried to fix the problem and almost everyone rejected it. And so enum is now discontinued.
Rest of the changes to TypeScript came from almost any other language but C#, probably the biggest changes ever to happen to JavaScript came directly from CoffeeScript. And then I personally saw how each of these new changes --- one by one --- arrived at C#. For what I have seen firsthand by reading the TC39 proposals, each feature came from a different community and different programming languages, (think about null operators !/?, the nullish coalescing ??, the incoming pipes, fat arrows and lambdas, mixings) as JavaScript is the only language everyone has to use, and it has benefited everyone to have a language that has all the great things from all other languages.
