[vbo]

Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages (not the Instagram variety). Basically all "modern" web UI.

[tarboreus]

Maybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be.

I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.

[martpie]

While I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad".

It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...).

I think the proportion of front-end developers knowing about accessibility is just low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue.

Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website.

So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.

[tarboreus]

The reality is that the education you're talking about is never going to happen. By the time you had 80% of devs knowing how to do a11y on JS framework #271, a whole new paradigm would have come in. It's because accessibility is not a priority that accessible defaults, which almost definitionally need to be system- or browser-based, are so important.

If you make a form with HTML and style it with CSS, then you're 85% of the way there with accessibility, and chances are it will be usable if you screw the rest up. With JS, even if you're working from a checklist, you're much more likely to get somethign wrong. And then there are regressions. I kind of believe that you know what you're doing, because the kinds of people that hang out on HN often do. But will your second-generation successor, four years from now, know how to update your work without breaking accessibility? Empirically, based on the low level of accessibility on the web (improving, but still pretty tough going), I'd say "no."

[torstenvl]

Did you really just tell a blind person they're wrong about the effect JavaScript has on web accessibility for the blind? Holy crap man.

[hotz]

I think sites that fail the accessibility test should be shamed into compliance. Possibly like how they handle sites that aren't https. I can just imagine how frustrating it must be to have an impairment that hinders usage of a website. Especially if it might be something essential.

[tarboreus]

It's mostly fine for me, because I'm technical and can do some weird thing or use OCR tools I made myself or whatever. It's incredibly difficult for the average blind person, who is statistically likely also to be older as well.

[eitland]

Good points.

I'm still not convinced it is worth everything we lost:

- Instant loading

- Sane page sizes

- Cross browser compatibility by default, including text based browsers

- Every page is reasonably safe by default

- CPU is idle after initial page load

- Battery life is great by default

and probably a few more.

I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad pushers and bored developers ;-)

Edits: yes, a number to clarify my points and to make it clear that I am open to change my views, at least slightly.

[vbo]

Agree on all counts except instant loading, you can still do server-side rendering (from the same codebase as the client) and have the client library bootstrap/hydrate its state from it.

[goatlover]

I mostly dislike infinite scroll and am irritated when I see visual things load after the page loads. I also don’t see the point in SPAs for regular websites. The modern web looks better, but sometimes the experience is worse, at least for those of us who were around before. Of course by this I don’t mean actual applications or games on the web. Just standard websites.

[easrng]

Modals can be done with CSS pretty easily (with either :checked and a label to activate the modal or :target and a link to activate it or with details/summary etc.), so can form validation (the required and pattern attributes), and lazy loading (add the loading="lazy" attribute for images and iframes). Infinite scroll can't really be implemented easily but in theory it's possible with server support (I'll make a demo and get back to you).

[easrng]

Here's the promised noscript infinite scroll! https://noscript-infinite-catfacts.glitch.me/