HTML was that way! "Hey, look, it's a spec where any computer can send a request, and you get a nice, structured text document back that's machine-parseable. It even words for the blind, who can just plug their own preferred reader into the doc! Problem solved."
Oh wait, except most of the audience isn't blind, and starts using clients that can do ever-zanier things with the UI. Designers want to appeal to this market. The beautiful, parseable structure of HTML gets forgotten about, and it's no longer usable by the blind.
So you want content providers to support an api endpoint that works like HTML used to? Okay, but what stops that exact process from happening all over again?
Or, maybe you mean that every provider in existence will support two versions of every endpoint: the meth-addled zany design, and the standards-compliant, usable one. Okay, that could work, but it seems a lot harder than just having one version that makes a small effort to make itself more machine parseable.
>and starts using clients that can do ever-zanier things with the UI.
From where I was sitting it seemed more like "brands demand 'consistent brand image', which they confuse with pixel perfect design because they don't really grok the new paradigm, and so any semblance of semantic web and accessibility dies".
And we've just now 15 or more years on clawed our way back to some semantics, and responsive design, and a legal framework that forces brands to accommodate those using different UA for accessibility reasons.
Yes, please. Accessibility requirements that push developers toward static or mostly-static pages tend to also help usability in general even for non-disabled users.
Too many web developers go for the full JS framework-heavy application architecture without stopping to consider if the project in question is trying to replace a native desktop app or if it's trying to replace a PDF document that could be printed on paper. The latter projects need to be pushed back toward simpler HTML.
Or to follow progressive enhancement: serve the core content quickly and accessibly and let JavaScript provide improvements. This usually provides significant performance and reliability benefits, too, because your visitors get the core page even if the more complicated code breaks.
That used to be the attitude for a number of sites. There was some form of accessibility mode. Also sometimes a separate mode for printing. The obvious downside is now you maintain multiple UIs.
But if you're doing anything that spits out HTML (flask, django, react, vue, whatever), you should be able to construct that HTML in an accessible way.
Oh wait, except most of the audience isn't blind, and starts using clients that can do ever-zanier things with the UI. Designers want to appeal to this market. The beautiful, parseable structure of HTML gets forgotten about, and it's no longer usable by the blind.
So you want content providers to support an api endpoint that works like HTML used to? Okay, but what stops that exact process from happening all over again?
Or, maybe you mean that every provider in existence will support two versions of every endpoint: the meth-addled zany design, and the standards-compliant, usable one. Okay, that could work, but it seems a lot harder than just having one version that makes a small effort to make itself more machine parseable.