> Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc [...] But so far, they seem to do badly when it comes to content address

> Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc [...] But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization. In my experience the key to solving accessibility etc, when building out a canvas-based web UI, is to work with the DOM instead of trying to replace it. Use <input> to control the placement and display of graphical elements, <button> elements to start/stop animations, etc; make good use of DOM events to track user movement/interaction across the canvas; tie clickable actions to real <a> elements instead of trying to reinvent them. Graphical text also needs to be reflected back into the DOM. Good use of ARIA also helps. Etc. And don't be afraid to tap into CSS --variables or even HTML data- attributes: not everything needs to be defined in the JS (or WASM-enabled language of choice) canvas code if the end result - a <canvas> UI or infographic - is destined to live in a web page. Proof-of-concept of an accessible design system: https://codepen.io/kaliedarik/project/editor/DVeMVj https://codepen.io/kaliedarik/project/editor/DVeMVj Proof-of-concept of an accessible set of related graphs: https://codepen.io/kaliedarik/project/editor/AMVKPx https://codepen.io/kaliedarik/project/editor/AMVKPx