Hahaha wow I have to say that was the least convincing demo I’ve seen.
- 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.
I disagree. I've built entire sites that rival the most popular SPA's today with HTML / CSS and a tiny bit of JS, and I've had less issues with those than other sites at my agency built with a JS framework. User reports often come in telling me "Wow, this site is so good! I'm really glad you took on this project".
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).
FF devs have to justify their jobs like any other. Someone was promoted for shipping a fancy-looking feature that some other browser, somewhere, probably has as default.
Still better than the Borg, at least you can fix it.
Yeah, seriously bugs me too. Scrollbars were one of the most powerful, useful UI components out there, and we had to sacrifice them because of mobile, for some reason.
Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.
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
I was more the opposite. I avoid learning JS for as long as possible since it seemed so complicated following the resources I tried to learn.
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.
Seems like aot of people misunderstand what these examples are best for. Sure you wouldn't want to ship these as-is on most sites, but it shows how much can be done without JS. That can/should make it more clear that you can likely get by with much less JS when you do need to reach for it.
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.
