6 ms·

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

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.

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.