The UI components that I wrote initially are just wrappers for the Browser provided input/form elements. As I'm relying on webview/webview to build desktop apps out of it, that also kind of implies WebKitGTK4 on Linux, WebKit on MacOS, and WebView2 (Edge) on Windows.

These work quite nicely together with a screen reader because you don't have to intercept the focus event (or others) that people browsing in caret mode or similar would use to navigate the page.

Additionally I decided to make single page applications using a main and section[data-view] elements so that the HTML and CSS alone is enough to hint screen readers on what's visible and so that there are no javascript codes necessary to tween things around, the JS/WebASM side of things literally just sets a data-view property on the main element.

The whole idea behind gooey and the way it is structured is:

- all states must be serializable in HTML

- Static HTML and CSS makes the page usable (apart from web forms and REST APIs, that's developer provided code)

- Dynamic WebASM on top essentially translates the DOM to be interactive, so that things can be animated based on changing data or streams coming from the backend. All interactivity is rendered directly into the DOM, so that it can be serialized again at all times.

- Communication between Client and Server is JSON or any other Go implemented Marshaller, and using Fetch API behind the scenes.

I decided on purpose to not provide XMLHTTPRequest and other old APIs because I'm relying on WebASM and "modern Browser engines" anyways. This way I kinda force users of gooey to use modern JS from the WebASM context and I save a whole lot of trouble with compatibility issues (and don't get into the unsemantic div fatigue like React does, for example).