You might like this: http://youmightnotneedjs.com/
- Fills history with massive amounts of entries, and back button doesn’t do anything
- Slider UI look like crap (ok fine, can be fixed) but use not just css but SCSS (requires a precompiler) but wait, not enough, it also needs hardcoded number of images. It’s not reusable in the most basic sense.
- Input validation has phone number on xxxx-xxx-… format and doesn’t fill dashes automatically. It’s also type=number which opens a numpad on iOS which does not have dashes available at all. I can’t proceed unless copy pasting a dash from somewhere else?
- Gave up after that but I’m sure there’s plenty more
Yeah, I’m leaning towards that JS isn’t the nemesis of accessibility. It’s simply not knowing what works and testing properly. It’s funny that frontend folks are seen as lesser beings and then counter-claims like this is passed as enlightened. Yeah on first glance maybe, but it’s proof that these regurgitated claims are made with very little insight. Like all tech, you have to know how to hold it right which takes a little time and humility to get right.
And yes, we still use too much JS. But it’s not the fault of JS or dev practices that we have newsletter popovers, cookie banners and 100 ad delivery and click tracking requests per page load. Indeed JS became extremely bloated for a while but nowadays everything is equally bloated, just look at all the backend snake oil with 1000 cloud microservices and leftpad-like APIs.
It tells you, by looking at a thin bar, how far down the page you are! What a novel idea!
I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll.
(Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horizontal scrollbar just won't show until you interact with the keyboard in some way).
You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage.
# scrollbar fixes
user_pref("widget.non-native-theme.scrollbar.style", 1);
user_pref("layout.testing.overlay-scrollbars.always-visible", true);
I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge case made primary.
Still better than the Borg, at least you can fix it.
Level 0 developer: don't know how to do this in JS Level 1 developer: knows how to do things in JS, even when sometimes it should not Level 2 developer: knows how to do things without JS Level 3 developer: knows when to use JS and when to use CSS or something else to achieve the goal
Ideally we’d have just a few more semantic elements that are obvious common patterns introduced to the HTML spec (like details & dialog were). We’re pretty close now, but I would like to see better accessible no-JS options for building menus.
It's not about throwing out JS, it's about avoiding 30kb of JS if all you need is a few summary/detail elements where only one can be opened at a time. Use the example code here then write a small I line script that closes all siblings. Done.