My question is why use the web at all? Surely there's an easier way for a blind person to access an information or send data to an API than through an HTML web page.
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.
That's effectively closing off a growing percentage of modern life from people with visual impairments unless you think that places which chose not to follow good web practice would be much better at publishing data to an API they use even less (Googlebot at least used to help accessibility because sites which were all Flash/images/JavaScript wanted to get indexed even if they didn't care about being accessible).
I would also reconsider why that “API” would be better than the existing web APIs which the community has been working on for the last few decades. HTML is great for this purpose: you have a rich document markup language with a decent semantic model, separation of display styling from content, and the ability to add metadata to support different accessibility modes. Using it to build applications is problematic but still possible: the main problem being that many JavaScript tools are developed by teams which don't prioritize accessibility, which is really the same problem as the previous paragraph where things which the people building the site don't check tend not to work. That's getting better but it really needs a combination of awareness of the need and legal ramifications to get people to build it in from the beginning.
I've been curious about this too. Instead of hacking around HTML to make it accessible, why not just have a completely separate page which is explicitly designed for low vision/screenreader users? Is this a 'separate is not equal' problem?
