The developers of screen reader apps are responsible for presenting the information to the user, just like a browser is. It is a mystery to me that they've managed to shove that burden onto every single developer who builds a website. The data is already there and Google manages to extract what's relevant, why can't the screen readers?
To me that argument doesn't make sense... It seems like arguing that because there are wheelchairs that can climb staircases, there's no need to make buildings wheelchair accessible.
I thing the problem with this argument is that it shifts the burden of serving all people (including disabled people) from the company providing the service to a person who is disabled. That's exactly what the ADA was supposed to prevent.
No, it's like if we had wheelchairs that were so broken and unstable, everybody had to build ramps with very special and hard to maintain padding on it, which varied between wheelchairs.
It's the responsibility of the wheelchair makers to at least build a reasonably stable product that everybody can support.
Web frameworks are already quite far from any "normal" use of HTML and Web technologies, TBH. They are the problem. Build your website using semantic HTML, test it in a text-mode, JS-free browser, and 90% of common accessibility issues are going to be solved for you, with the remaining 10% still being quite easy to address.
This. I have a strong suspicion that the web was inherently more accessible 10 years ago when it was written in -- you know -- HTML. But now it's not written in HTML as much as in Javascript frameworks, most of which are necessary only to add "flash" (no pun intended) to modern websites but which also hinder accessibility.
Web developers need to decide if their job is to impress or to inform. Usually users want to be informed, while the VP of marketing (your client) wants to be impressed. The two goals do not have to be in conflict with each other but the blind use of frameworks and client-side rendering often puts them in conflict.
Alternatively, there is the approach taken by segments of the US government: choose (and buy) an accessibility test system, point it at the apps, and fix what it reports. Pro tip: single-page apps will routinely pass with no changes.
When I bring up that some accessibility improvement to support the blind doesn't help the deaf-blind (who have much reduced screen readers), the people pushing for accessibility brings up that it would be too costly to support everyone. The irony seems lost on them.
Oops, should be deaf-blind. But you're right: I may have accidentally stumbled upon a market that, apart from cryogenics, has nearly zero products marketed toward them. And what of the living? Why can't they get the whole "dead" experience without the full commitment? I see DaaS (death as a service) with monthly subscription as a completely untapped pool of demand.
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?
Perhaps one way to approach the issue is for people who build web frameworks to reconsider their anchor of "normal."