Disable ESC key to close modal

[kalpeshsingh]

Use case - User wants to use micromodal to display a "We use cokies" message and don't want visitors to close the modal until they agree or disagree

Ref. https://twitter.com/imariohernandez/status/998704962212265984

[iantbarker]

I would like this feature as well. I understand the concern about accessibility but I would like to use a modal that user is unable to close until they perform an action.

[4nd3r5]

Does anyone have a solution for this, a hack or similar?

[ghosh]

As a project we decided to take a stance on what a accessible modal should be. Disabling modal close on esc goes against this very belief. This is most likely will not become a part of this library.

Understandably, this feature could a deal breaker in some scenarios, however there are plenty of modal libraries which would fulfill this need.

[KCErb]

I have a solution and a hack:

Solution

The team is right! Don't try to prevent escape, it's not good UX. In your modal let the user know that ignoring or closing the modal brings with it default behavior. It's quite common to see something like this with respect to GDPR.

Consider Gitlab's homepage, at the bottom (today) there is a footer with cookie options and a button. "You consent to our cookies if you continue to use our website." That's default behavior in action, but of course be careful about default opt-in, in some cases you must default opt-out of certain kinds of data collection. Either way, a default should be available and esc can perform that default (just use the onClose callback).

In my use case, the user starts a long-running web worker and if their data has certain properties the worker pauses to ask "Should I use method A or method B to continue this job?". It can't go on without a choice, what should I do if they hit esc?! This was hard for me at first but all I have to do is add to the modal "if you close this modal, the job will be canceled". Or "hit escape to cancel". I originally thought I would hide the x button, turn off the "clicking overlay closes the modal" and such, but that just frustrates the user. In short, for a modal, there should always be another option: I don't want to deal with this modal right now!

Hack

If you really love this little library, but you just gotta turn off that escape feature, then just remove it. It's a pretty small library, there's one simple line of code that closes the modal on escape. So you could just:

1. Download the source or the minified version (you can unminify it with an online tool).
2. Look for the number 27 (that's the escape key code).
3. Now you've found the place that checks keyCode and closes the modal. Just remove this line.

[kun101]

I had the same problem when using Micromodal.js, like, 5 minutes ago,
if you don't want to download the library or go to change the source code,
I have a hack that works even on the CDN version :

I do this in two steps :

1. Prevent closing the dialog on clicking the "Modal Overlay".
2. Prevent closing the dialog on pressing the escape key.

I think it is number 2 which you were looking for

1. Number 1 is pretty easy, just remove the data-micromodal-close attribute to prevent closing the modal on clicking the "Modal Overlay".

2. Using jQuery to stopImmediatePropogation() of the escape key (keyCode = 27) event by doing this,
   (even though it might not be the best solution in your case)

   $(document).keydown(function (event) {
if (event.keyCode === 27) {
event.stopImmediatePropagation();
}
});

[GR1ML0CK]

This really doesn't have anything to do with accessibility. Accessibility is about ensuring that features that are expected to be "accessible" to any standard user are "accessible" to all standard users (i say standard because some features could be restricted by unrelated things like paywalls).

If a modal is not meant be closable by any user, then that would include users that require the use of assistive technologies.

The WCAG guideline that outlines the use of the ESC key to close modal is to make the modal close function (not the modal) accessible to users that can only use keyboard commands. This feature is specific to making the close functionality accessible to all user. In general term, again, all feature/information should be accessible to all users. If a feature doesn't exist in the first place, then there's nothing to make accessible.

For the same reason there's no reason to add alternative text or title to hidden elements, since the intention is that no one consumes this information (screen readers wont even read these anyway for this reason).

As far as what is the best UX, that's not even a concrete thing. UX is a highly subjective topic, and more importantly a very distant second to what a client want for their site.

That said the maintainer of this project are free to do as they like. It's their project. I've built my own modals from scratch, but i like most ppl don't have time for that (ain't nobody got time for that), so if you're going to use plugins, you're going to be restricted to the present features & functionality

[gokce]

If a modal is not meant be closable by any user, then that would include users that require the use of assistive technologies.

100%
Imagine using this library for a modal that is shown while processing a payment. In that case, modal is not meant to be closable (button or ESC), user has to wait until it's done or until it fails...