Hacker News Reader

Comment by roebk | Hacker News Reader

It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users.

Be sensible and use JavaScript when it's appropriate. Please don't think it's cool to create some fancy JS-less widgets and forget about accessibility.

View on HN

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?

While I recognize a lot of the HN crowd blocks Javascript, the overall percentage of people doing this is absolutely tiny.

What is the case for making Javascript-blocking users a priority?

Security matters, and blocking JS blocks the majority of vulnerabilities on browsers. We should help users who want to protect themselves.

No. If I develop an interactive website, I'll be damned if I try to also keep the No-JS folks satisfied. Either you trust me, or you don't.

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)

But why should he put time into supporting you?

Why should I use his app?

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.

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 argue why you don't trust me, when I'm arguing that I'm not responsible for negative impacts in the case that you do not trust me.

ok, i don't.

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?

>Either you trust me, or you don't.

Can I sue you if your website serves me malware? Because that's the concern.

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?

If you're hotlinking them, I don't trust you.

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.

Many won't and visitors will leave. New visitors will bounce more often. Users with trust for every site is low until earned.

It's not just modals. Hidden but toggled via labeled checkboxes — how are they gonna play with screen readers?

How do you properly shift focus to the dropdown menu whose visibility is toggled by clever CSS tricks?

And yes, modals may be needed sometimes especially in payment forms even if that modal is only visible to the screen reader.

NoScript users aren’t disabled. There is no reason to even consider people that willingly disable themselves.

> block JavaScript

How did we even get here? I remember when we used to hide javascript inside of comments to support user agents that didn't speak it.

Also: be sensible about accessibility when writing JavaScript SPAs. If your page consists entirely of nested <div>s without any semantic markup, you're going to have problems (and perhaps risk a lawsuit).

This can’t be true, right? A ton of major applications (Google’s for starters like GMail) have some layer of post processing or obfuscation (or maybe it’s just compiled) to their generated DOM that results in a ton of nested divs with gobbledygook classes.

It's not the DIV-soup that is an accessibility problem (though that's what often takes the blame), it's the lack of adding accessibility attributes (`aria-*, tabindex, title`, etc.). Lots of builtins, especially form elements, give you many accessibility traits "for free", but there are a wide variety of ways to tag a bowl of DIV soup for accessibility.

Then there's "semantic HTML(5)" (`<article>, <section>`, etc.), which still exists, but is not _particularly_ worthwhile for accessibility: Too much of the web lacks these tags, so most common consumers of this nature (scrapers, screen readers, content summarizers) use other, often AI-based, strategies to tag content semantics.

Ah interesting thanks for the info. I'm now wondering how accessible GMail for instance is. I'm see a lot of tabindex and aria-labelledby but the values seem to be garbage as well. But I temper that against my assumption that GMail, being such a universally used application, must have some mind towards accessibility.

Totally agree on your statement. It's not possible to build modern solutions that are accessible without using some JavaScript. It's always a matter of where you want to go. And it's easy to spare e.g. modals. The question is just if you can solve user experience issues with just HTML and CSS for all use cases.

On the other side, there are more solutions built into HTML and CSS one thinks. In your particular example, you can use the HTML dialog element and get built in keyboard and focus management (still requires a polyfill for many browsers).

Just to play devil's advocate: why use a modal in the first place instead of just opening a new page?

I'd reckon it's easier to share data between parent and child, than between completely different pages.

Less jarring to the user, creates the UX where the user knows their state is still there once they dismiss the modal, less commitment overhead, etc.

I find the opposite is true. I can't count the number of times I've accidentally closed a window or backed out of a page using a modal where the semantics were unclear or the comically tiny 'x' was hidden below mobile-Chrome's sliding address bar on a page that was too short to scroll.

It seems like the modal is often abused as an anti-pattern, where it's not even clear if you are still on the same page because the content is almost entirely concealed/darkened. Reddit desktop is an example. Modals with multi-page length scrolling content is just absurd

You haven't seen how many tabs my wife has open. If you send her to a window, she's never getting back :)

Agreed on the modals, but this is a non-unique problem. Accessibility just takes work, whether it is fixing JavaScript libraries or supplementing CSS only solutions. And since performance and accessibility often suffer together at the hand of these JavaScript libraries, it is encouraging to see that there are other options for building good user experiences.

Reply on news.ycombinator.com