Yep, just to confirm, this is what Chris said:
The initial request is just a plain old HTTP request and HTML response, so screen readers and crawlers will see the LiveView’s static HTML. After render, the browser reconnects and the LiveView process is spawned on the server.
It is uncommon, though - statistically.
0.2 - 0.7% worldwide.
A company (or just an individual developer that values their time) building apps needs to consider whether a) that 0.2 - 0.7% represents their target demographic, and b) whether the have the time/resources/interest in creating (often large-scale, and sometimes unfeasible) workarounds for JS-only functionality to serve that traffic.
GraphQL on the client-side is one of its major selling points.
In ReactQL, the out-the-box demo component I provide pulls stories from HackerNews via SSR and delivers the result in React-rendered HTML:
Subsequent requests to a GraphQL API server (or routing) are performed on the client, cutting out the need to round-trip to a server to rebuild HTML.
This leverages the capabilities of 99%+ of browsers in exactly what they were designed to do.
Modern screen readers can parse JS.
From WebAIM: Accessible JavaScript - Overview of Accessible JavaScript :
> It is a common misconception that people with disabilities don’t have or ‘do’ JavaScript, and thus, that it’s acceptable to have inaccessible scripted interfaces, so long as it is accessible with JavaScript disabled. A 2012 survey by WebAIM of screen reader users found that 98.6% of respondents had JavaScript enabled. The numbers are even higher for users with low vision or motor disabilities. In short, people with disabilities will experience scripting, so scripted content must be made natively accessible
^^^ Server rendered initial HTML answers that concern.
Well, yeah. If your demographic isn’t ‘the world’, then design accordingly. That goes without saying.
None of the apps I’ve built the past decade, for myself or for clients, have been for government departments with locked-down JS.
Right, but it’s still exceedingly uncommon to consume a website - as an individual user - outside of Chrome/Safari/Edge, even with a screen reader. And if you’re surfing without a GUI, you can’t expect a site to accommodate this slim use-case beyond basic HTML.
Fewer sites/apps these days even make sense in a HTTP verb-only context. There wouldn’t even be ‘static’ ways to represent functionality of most of the things I typically build now beyond the initial HTML render.
I think accessibility standards are being incorrectly conflated with a philosophy that eschews Javascript.
That’s from a UK-centric survey, worldwide the value seems to average 1.1% with some countries averaging well over 2% and TOR users averaging over 10%, so it all depends on your focus as well.
However, that’s of people that are specifically disabling javascript on an entire page, that does not include people that use Ad Blockers (that block most 3rd party javascript) nor of matrix blockers (like uMatrix, that can block a whole lot more and specifically whitelist paths), and especially it does not include people using interfaces that don’t support javascript.
Rather they should just not start backwards and instead start with HTML and only add javascript to enhance interfaces, not require.
Yep, that’s the useful thing of using it everywhere, you know it works and is well tested, and its trivial for a client to progressively enhance to use it while working without JS. 
Funny enough, their homepage is fully functional without javascript, there is not even any first-party javascript at all and the javascript just seems to add some animations and embed youtube and so forth (though you can easily have a video on the page without javascript too, but eh). ^.^
Yep yep, that’s part of progressively enhancing, everything works without javascript but it just becomes ‘better’ and more efficient with javascript.
Not at the college here (well not any JS above some ancient standard, not even react works with it).
Those sound like ones that are browser addons, the ones we are required to use are not because they reach a required level of ADA compliance for the college.
That’s been my life for the past… wow its been over 10 years of work now… >.>
The past 3 years I’ve been having to dev ‘for’ it as well (not just forced to use things without javascript as the previous 8 years before that).
It may not look pretty, but I sure have the expectation to be able to at least read the ‘content’ of the site that I’m going for, whether a blog entry or stack overflow request or something, but just seeing ‘Nothing’ or “Please enable your non-existing javascript” is entirely bad form. Sure request javascript for enhanced features, but at least let me read what I came to read… >.>
I absolutely don’t eschew javascript, and use it when I can (whitelisted via uMatrix so most sites actually load decently fast, literally its the difference between a half second to load and 30 seconds to load on some sites…), just it should not be required for the ‘base’ functionality. Chat interfaces, real-time web games, push-requests, all those and more are absolutely fine in javascript even if you could ‘mimic’ it inefficiently with just HTML and SSR, but at least let the site ‘work’ for what makes sense without it. ^.^
Their website is my web page
I designed ReactQL with SSR for exactly that reason.
Although I think that page is a poor example, because it’s literally just HTML. There’s no functionality to speak of.
Very different to, say, a back-office app.
Hehe, well I love it, it worked sans javascript so I didn’t even need to whitelist anything and yet it was all usable. ^.^
