Hacker News Reader

Comment by steelframe | Hacker News Reader

> using the web normally

Perhaps one way to approach the issue is for people who build web frameworks to reconsider their anchor of "normal."

You can hate the deficiencies of screen readers and accessibility specifications while still supporting the individuals who need to use them.

Reading OP it seems like his team is shouldering a disproportionate amount of what should be a shared burden.

What burden do you think should be shared by whom?

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.

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.

Sigh.

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.

Component frameworks can choose to have deep support for the ARIA accessibility tags e.g. Dojo had it in 2007 - https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/stat...

Using a framework that is designed for accessibility should be better than using plain HTML that is not designed for a11y.

Claiming that "web frameworks" are the problem is such a general blanket that it ceases to be a useful statement at all.

React and declarative frameworks make it as easy as vanilla HTML to include ARIA compliant content.

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.

What sort of screen readers are available for the dead-blind? Braille?

> What sort of screen readers are available for the dead-blind?

None at all, even though the dead-blind greatly outnumber the living-blind. This area is ripe for technological disruption.

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.

It feeds it into a single line of braille they can read. You can imagine why any complicated site becomes an extreme pain to interact with.

We detached this subthread from https://news.ycombinator.com/item?id=20224672.

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.

A lot of services in higher ed are only available online. The alternative solution is to have someone whose job is to use the web for blind people.

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.

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.

So is it easier just to provide static web pages for accessibility?

I'd be ok with that, personally. I'd set my browser to use that version of a site by default.

That’s what “reader mode” effectively is.

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.

Well, yea, it can be easier. I find it easier.

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.

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.

If nothing's changing on a web page, it should be static. It should only use JavaScript if stuff needs to change after the page is loaded.

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.

>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.

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?

Will you be the first to gouge out your eyes?

Reply on news.ycombinator.com