You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users are involved.
Personally, I try to avoid modal popups altogether. There is almost always better ways to structure things. The whole concept of "modal" UI doesn't map well to the "document" nature of web elements.
This is not simply about modals. Using VoiceOver and Chrome I cannot access the pop up menu to navigate the site. These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing.
More specifically, no you cannot add keyboard shortcuts "with 0 rework". How are you returning the users focus to the active element before they opened the modal? The key is not to use an "arbitrary JS library for modal popups" and to use or create a modal library that has superior usability baked in. Sure, maybe there's a superior workflow than to use a modal.
For anyone that is interested MicroModal (https://micromodal.now.sh/) ticked a lot of boxes last time I checked.
>These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing.
The same can be said about any JS library that interacts with page controls.
The wast majority of modal dialog implementations on the web do no follow the standards you're referencing. Do you routinely criticize websites on this basis, or is this criticism only reserved for ones that use vanilla HTML+CSS for core functionality?
>More specifically, no you cannot add keyboard shortcuts "with 0 rework".
Yes, you can. 0 rework != 0 work. Anything that unchecks that checkbox on Esc will close the modal. To implement that you don't need to change the structure of what you've already done. Progressive enhancement.
>How are you returning the users focus to the active element before they opened the modal?
Focus management has absolutely nothing to do with where the state of the modal is stored. You can implement all of the usability features you want on top of Checkbox + CSS solution with the added benefit of not screwing everyone who can't run your scripts or completely breaking the website for everybody if something in your JS gets broken.
> The same can be said about any JS library that interacts with page controls.
Difference being JS, if written by an averagely competent individual, can be changed once and this change will apply to any instances where it's called, and this cute pattern will need to be manually updated in any number of places where it's applied, one by one.
> Yes, you can. 0 rework != 0 work.
Rework meaning you have to go back over the "done" thing and then do more to cover the technical debt. On each and every instance of the thing.
> if something in your JS gets broken
As opposed to replacing the cute styling trickery for browsers that don't really support it, which is somehow better?
A reasonable argument iff you use no external libraries, or personally audit every one of them completely (including all updates). Otherwise maybe I trust you, oh random person on the internet, but should I also trust the 49 authors of the 37 libraries you're including from 4 different CDNs? (Bonus points if you run ads and let under-vetted 3rd parties inject whatever they want into the page)
Interestingly I've had this debate with at least one person on hacker news who was complaining about how people were stealing from his website by running ad blockers, and how he'd tried to fight them but it had left his website looking broken for anyone who was running an ad blocker, so he'd had to roll it all back. Why would he do that?
The answers actually pretty simple. People who are interested enough in technology to read hacker news are both disproportionately likely to discover a new product trying to build an audience, and disproportionately likely to influence their friends either for or against that product. They're trusted by their non-technological peers.
So why support script-blocking hacker-news users? Because if your website doesn't work for them, they're gonna tell all their friends that your product doesn't work properly. When I got my first job, I was told that on average satisfied customers tell 2 friends they were satisfied, and dissatisfied customers tell 12 friends they were dissatisfied. I don't know how accurate those stats are, but I do know people complain more than they praise.
I certainly go out of my way to warn friends and family away from products that I feel are committing technical faux pas. How else will they know they're using websites made by people of limited technical capability, with all the risks that implies, if I don't tell them?
You don't have to use his app, and he doesn't have to support users like you.
It's a two-way thing: many developers don't want to support people that switch off JavaScript, and these consumers are apparently happy that they can't access the majority of the internet (or so they say).
I think that's a slight misrepresentation; developers don't want to invest the (significant) effort to run without JS, and some end-users are unwilling to take the risks with allowing arbitrary code execution in their browser. But I doubt that developers (generally) don't want to support noscript; if it were 0 effort than I expect it would be common. And such users aren't happy that they can't access a lot of sites, they just find the tradeoffs unacceptable.
That said, aside differing biases I'm not convinced that we actually disagree.
Some "interactive" websites have to use javascript, it's true, but it always seems tragic when a site that doesn't really need to requires it anyway. Isn't there something appealing about a platform where millions of strangers can converse and publish information without needing to fully trust one another?
Do you vendor your javascript libraries and host them from your own domain, or do you just hotlink them from random CDN's all around the internet like everyone else?
One could use Subresource Integrity (https://hacks.mozilla.org/2015/09/subresource-integrity-in-f...) to mitigate the most obvious threats from CDNs. Granted, that does have some maintenance work, but if you're already managing dependency versions (and you really should) then it's minimal extra work.
Correct me if I'm wrong, but all the scripts the website owner hotloads have to also use subresource integrity for the scripts they are hotloading, or subresource integrity gains nothing beyond the first level of script loading?
I rarely feel that website owners out out to get me, my distrust comes from scripts that load scripts that load scripts. Lets not piss about, I know most people who have written websites that are loading jquery from a remote CDN haven't bothered to inspect it to see what it's loading. By contrast, a website that has vendored all it's script dependencies has looked at the entire dependency tree at least /once/. That shows a baseline level of competence that I'm willing to extend trust on top of.
Personally, I try to avoid modal popups altogether. There is almost always better ways to structure things. The whole concept of "modal" UI doesn't map well to the "document" nature of web elements.