5 ms·

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 b

by 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?

by roebk 8y ago

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?