11 ms·

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

by roebk 8y ago

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.

deleted 8y ago
[deleted]
gambler 8y ago
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.
- roebk 8y ago
  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/ https://micromodal.now.sh/) ticked a lot of boxes last time I checked.
  - gambler 8y ago
    >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.
    - cfv 8y ago
      > 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?
- Wowfunhappy 8y ago
  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?
  - yjftsjthsd-h 8y ago
    Security matters, and blocking JS blocks the majority of vulnerabilities on browsers. We should help users who want to protect themselves.
    - cuddlecake 8y ago
      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.
      - yjftsjthsd-h 8y ago
        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)
        lhnz 8y ago
        But why should he put time into supporting you?
        yjftsjthsd-h 8y ago
        Why should I use his app?
        lhnz 8y ago
- dmitriid 8y ago
  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.
- Aeolun 8y ago
  NoScript users aren’t disabled. There is no reason to even consider people that willingly disable themselves.
- c22 8y ago
  > 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.
lhorie 8y ago
Just to play devil's advocate: why use a modal in the first place instead of just opening a new page?
- cuddlecake 8y ago
  I'd reckon it's easier to share data between parent and child, than between completely different pages.
- hombre_fatal 8y ago
  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.
  - c22 8y ago
    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.
    - squish78 8y ago
      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
- automathematics 8y ago
  You haven't seen how many tabs my wife has open. If you send her to a window, she's never getting back :)
jasonhansel 8y ago
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).
- khalilravanna 8y ago
  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.
  - kremonte 8y ago
    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.
    - khalilravanna 8y ago
      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.
deleted 8y ago
[deleted]
oh_boy 8y ago
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).
strouptl 8y ago
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.

by roebk 8y ago

deleted 8y ago

[deleted]

gambler 8y ago

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.

roebk 8y ago
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/ https://micromodal.now.sh/) ticked a lot of boxes last time I checked.
- gambler 8y ago
  >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.
  - cfv 8y ago
    > 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?
Wowfunhappy 8y ago
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?
- yjftsjthsd-h 8y ago
  Security matters, and blocking JS blocks the majority of vulnerabilities on browsers. We should help users who want to protect themselves.
  - cuddlecake 8y ago
    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.
    - yjftsjthsd-h 8y ago
      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)
      - lhnz 8y ago
        But why should he put time into supporting you?
        yjftsjthsd-h 8y ago
        Why should I use his app?
        lhnz 8y ago
dmitriid 8y ago
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.
Aeolun 8y ago
NoScript users aren’t disabled. There is no reason to even consider people that willingly disable themselves.
c22 8y ago
> 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.

lhorie 8y ago

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

cuddlecake 8y ago
I'd reckon it's easier to share data between parent and child, than between completely different pages.
hombre_fatal 8y ago
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.
- c22 8y ago
  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.
  - squish78 8y ago
    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
automathematics 8y ago
You haven't seen how many tabs my wife has open. If you send her to a window, she's never getting back :)

jasonhansel 8y ago

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).

khalilravanna 8y ago
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.
- kremonte 8y ago
  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.
  - khalilravanna 8y ago
    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.

deleted 8y ago

[deleted]

oh_boy 8y ago

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).

strouptl 8y ago

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.