Thanks for great accessible modal dialog script. I've been looking something like this for a while.

I understand perfectly why there is id="main" or passing the ID as a second parameter. However when I wanted to use this script in public WordPress Plugin where I can only take educated guess about ID names. In other words I don't know html markup.

I guess my question is that would second parameter also be false if I have no clue about the markup?

Edit: A11yDialog has been chosen. Please check https://github.com/edenspiekermann/accessible-modal-dialog/issues/22#issuecomment-187626418 to give your opinion!

Modal seems a bit too generic for a global variable. It would be a good idea to find a better name. However it will be a breaking change (v2).

Ideas:

• AccessibleModalDialog (a bit long?)
• AMD (probably not a good idea)
• ESPIDialog (not a fan of branding everything)
• AMDialog
• A11yDialog
• Any other suggestion?

This is a proof of concept that would make all events go through the DOM under the hood. This would mean they would no longer be attached to the dialog instance itself, but on the dialog DOM container instead. This just reduces the amount of code shipped (not by a lot though).

~The way this is implemented would likely cause no API breaking change.~ The object passed to the events would now be a CustomEvent, and accessing the underlying DOM node would require reading event.detail.currentTarget instead of event.currentTarget, so this is a breaking change.

We could also decide to drop .on and .off methods entirely, but it might be good to keep them for convenience. Otherwise the API would be a little awkward (having to read the element from the instance to bind listeners).

I know that the recommendation is to have this css:

[aria-hidden="true"] {
  display: none;
}

However that solution leaves much to be desired in terms of in-out transitions using CSS.

Since the modal code already implements the ability to disable focus on elements, as used on the modals siblings, would it be possible to do the same thing for the modal content when closing the modal?

This would enable the ability to use other means of hiding the visual side of the dialog when closing it, which includes transitions in and out.

This is not an issue per se but I wonder about the position of the "close" button in the markup. I believe sighted keyboard users would expect to reach the button after tabbing out of the heading—since that's the visual flow.

What about having 2 buttons? One after the heading and one last in the dialog? With the same styling/positioning of course. Does that make sense?

Not so much of an issue that needs fixing but it might be useful to mention in the docs:

While implementing a11y-dialog in a website I ran into a strange issue due to Safari’s user agent stylesheet. This is a fullscreen dialog, the dialog content spans the whole screen. As soon as the dialog opens focus is set on the dialog container. Safari applies user agent styles for the focus which then hinder the performance. For instance resizing the browser becomes very choppy. Also when you’ve applied animations to the dialog these don’t run and skip to the end immediately as Safari is struggling. The solution I’ve used to resolve this is to set .container:focus { outline: none}.

Hi,

thanks for great modal dialog plugin.

I used it in my project where I use one dialog instance to display details about team members. Information is in the markup, so I needed to detect which team member modal dialog is open to inser proper data. For this reason I did modify the script so event detail property contains element which actually triggered show or hide event.

I believe this could be useful to others as well so I would like to merge it with your repo, if you are interest.

First time contributor. Posting for feedback before jumping into tests, docs and examples. Hopefully its a small, non-breaking change.

Adds support for role='alertdialog', making the dialog modal by not closing it when the escape key is pressed. Note that the data-a11y-dialog-hide attribute should be removed from the overlay as well to comply with the specification.

Closes #83.

I have a setup where I open a modal and then want to step from the currently open modal to the next one. From the second modal I want to go to either the previous modal, or the next one, and so on.

The pseudo-code of the buttons inside the modal that enable this behavior:

Modal 1

<button data-a11y-dialog-hide="modal-1" data-a11y-dialog-show="dialog-2" >next modal</button>

Modal 2

<button data-a11y-dialog-hide="dialog-2" data-a11y-dialog-show="dialog-1">prev modal</button>
<button data-a11y-dialog-hide="dialog-2" data-a11y-dialog-show="dialog-3" >next modal</button>

… and so on.

Now, when I click on the "next" button in the first modal, everything works as expected, the modal 1 hides and modal 2 shows up. In fact, the "next" button of all modals works just fine.

But when I click on the "prev" button e.g. in the second modal, to go back to the first modal, I get the following error in Chrome, Opera, and Safari (aka. Blink and WebKit browsers):

Uncaught RangeError: Maximum call stack size exceeded.

Test scenario: http://jsbin.com/bumimohexi/1/edit?html,js,output

What is causing this and how can I avoid it?

When we open a dialog, it put aria-hidden attribute to true for each element of document other than dialog itself.

And when we close the dialog box, aria-hidden attribute is removed to each of them.

But when an element is aria-hidden="true" yet before opening, a11y-dialog remove the attribute at closing, but it shouldn't.

Use case: I want to display a form in the dialog. When the user accidentally clicks outside the dialog or on the close button, the dialog closes without warning. I could check in the hide event listener if the user has already entered some data and confirm if they really want to close.

It would be great if I then could just return false in the event listener to cancel the action. Maybe a beforeHide event would also be valuable.

The same can also be applied to the show event, though I guess it won't be too helpful.

Summary

This overhaul of getFocusableChildren replaces querySelectorAll with a manual, recursive DOM traversal. This traversal is necessary because there's no way to query into shadow subtrees.

I have ideas for tests, as well, but I will follow up with them in a separate PR to keep this one small.

Huge thanks to the inimitable @alice for listening to me complain about Shadow DOM and helping me figure this algorithm out.

Relevant issues

This, ideally, closes #322.

We have a workflow where we fetch the modal content from the server when the modal trigger is clicked. We want to give the user some feedback, so we show the modal backdrop with a loader and then dynamically add the modal content when the response comes back from the server. What I'm noticing, though, is that the modal close doesn't work with this workflow. It appears that event handlers are registered on any existing "hide" elements when the modal is first shown, but if the close icon is added after the modal is shown then it doesn't work.

We can work around this on our end by tracking clicks to the close button ourselves, but I wonder if there is an event delegation based approach that might work in a11y-dialog in order to support elements being added later.

Would it be possible for this library to get history api support, like one described there? https://github.com/jamesnuanez/history-api-with-modals-demo

I think it would be especially useful on mobile devices where users are used to closing modals with back button.

I played around a little with implementing it using a11y dialog events but didn't sucedeed.

Scott O'Hara writes:

It’s now March of 2022, and Webkit 15.4 has shipped the <dialog> element, as well as Firefox 98. All major browsers now support the <dialog> element, and that’s really exciting.

Please note that you should definitely start (continue) tinkering with the <dialog> element. There are still ongoing discussions about some aspects of the <dialog> element, but things are looking promising.

We are building a web component that uses a11y-dialog—this is similar to the framework implementations of the library but for web components.

We've noticed that focusable elements within shadow DOM are not picked up by the logic in _maintainFocus. This is because event.target.closest is not able to see into shadow DOM.

I'm wondering if you're open to a PR (and/or collaboration) that would upgrade this logic with shadow DOM support so this library can work properly with web components.

Thanks in advance!