This is just a bad idea. Apart from abusing browser rendering quirks (which is unfortunately a sad tradition of the web, something that has claimed the life of entire technology stacks like xml/xhtml), it removes any hope of producing webpages accessible from screen readers and similar. In comparison, JS-only pages look like model citizens. This is the equivalent of abusing IE hot-comments and other CSS-parsing bugs to style your website, but worse (at least that technique was useful).
If JS generated sites can support ARIA then I don't really see why this couldn't do the same thing since it's just a JS site with a funky initial payload.
The "fun" of this site is that it's its own API. Sure there are better ways to accomplish this but abusing quirks for fun and profit is the hacker spirit.
Hacking is mostly playing around and using things in ways the designer didn't imagine at the time.
This is a good hack. It brings a smile to the face and warms the heart (if a good hack is what you were looking for). And I think that was the point anyway, not to come up with a professional architectural pattern.
So long as the JavaScript executes, this doesn’t actually harm accessibility: as it loads, it slurps the JSON, and turns it into a perfectly normal web page; rather like XSLT, as others have pointed out. And quirks mode isn’t that serious a problem. It’s a mild nuisance at most, really.
I disagree with this removing any hope of accessibility. If anything it brings hope for websites to be more accessible than ever before. Imagine a screen reader that instantly and flawlessly knows which content to read and how to navigate through it? If a consistent JSON format is adopted and used this would be a reality.
You’re misunderstanding the purpose of this JSON/HTML combination, and I get the impression you’re probably not familiar with how screen readers work, either. The JSON is purely transient, being projected to the HTML DOM. The JSON has no standard semantics; the idea is that it should be whatever shape makes sense for your use case, and then that you should use JavaScript to project it to HTML. Think of it as a server-side templating language that takes a bag of data and decides how to write the HTML, except that the document is the data, plus an extra piece that embeds the template to apply to the data.
The web is pretty much best-in-class for accessibility matters. (There are a few isolated cases where native desktop or mobile apps can do better, mostly to do with efficiency.) HTML elements have defined semantics, so that things like headings and links are automatically navigable, and sections, headers, footers and navigation lists become waypoints. Then ARIA attributes can be used to provide any further metadata necessary, such as to mark up a tabs widget to show how to interact with it. And that’s still key—accessibility needs to care about interactions (which tab is open? and did the content available change?), so state matters. Thus, accessibility tools will never care about any format that you are projecting from, like this JSON; they must only care about what is materialised, which is the HTML DOM. (Besides all that, the only sort of “consistent JSON format” that you could have would be basically an encoding of the HTML, which would be verbose and subjectively ugly compared to the HTML serialisation, e.g. ["a", {"href": "/"}, ["Home"]] or {"tagName": "a", "href": "/", "children": ["Home"]} instead of <a href="/">Home</a>, and miss the whole point here that the JSON is representing data rather than what the user sees.)
If you’re not familiar with accessibility stuff, I heartily recommend looking into it. If you can, find a blind person and see if you can watch them using a computer or phone. It’s really fascinating (I’ve never seen anyone be bored by it) and super useful if you ever contribute to making just about anything on a computer. Even people making documents in a word processor can learn things like “use actual headings rather than just making the text bigger and bold, because the semantics are useful”.
