DEV Community

Cover image for Accessibility first: Dialog
Andrew Bone
Andrew Bone

Posted on • Updated on

Accessibility first: Dialog

It's time for another blog post, this time I'll be making a dialogue pop up. Those of you who have read some of my earlier posts may know that I wrote about the native <dialog> element but support is still a bit patchy, it only works on Blink based browsers.

The humble dialogue box has existed in UI and UX design for a long time and everyone has their own way of implementing one. JQueryUI, which those of us of a certain age will be well aware, was the most common method but why load an entire library for just one feature?

I'll be taking another approach, I'll be using the ever-versatile <details> element that does, of course, mean still no IE but it's a start. Here's the finished product. I'll explain the whats and whys as we progress.


As always, the aim is to support keyboard users as well as mouse ones, let's take a look at the spec and see what we can see.


  • Tab Key, Tab to the next selectable item (the browser handles this by default)
  • Shift + Tab Keys, Tab to the previous selectable item (the browser handles this by default)
  • Escape Key, Hide the dialogue


For the mouse, there are two simple rules click inside the dialogue to interact with items as normal click outside the dialogue to close the dialogue.


As I said earlier I'll be using the <details> element which has a bunch of functionality I want natively built in.

As you can see all the bare bones are there but we can't really call it a dialogue. We need to break that bottom section away but that's what styles are for.


I don't tend to go into too much detail went describing my styles this is just how I chose to do it. If you know a better way or wonder why I did something a specific way feel free to ask down below 🙂

And there we have it. It looks right so let's just leav... Oh, it opens of OK but there's no way to close it. That's not ideal, it's time to look at the JS.


I'm using an ES6 class to contain my controls and listeners, you don't have to do it this way but if we're not supporting IE anyway, why not?

The <details> tag changes based on an open attribute which we can take advantage of in order to move our controls to the JS. Pressing the <summary> "button" will still work but we don't need to rely on that.

Also, we've added listeners for clicks and the escape key. Javascript is great for adding all those little bits of functionality you need once all the main building blocks are in place.


That's the end of another post, thanks for reading. You may, or may not, have noticed I haven't been posting as much as usual. This is because I got a new job 🎉🎉. It's great and exciting but doesn't leave much room in my little brain for things like this. Hopefully, as time goes on, I'll get back into posting more regularly.

If there is anything in this post that you didn't understand or that I didn't understand feel free to post about it down below.

Thanks again.

Discussion (4)

thekashey profile image
Anton Korzunov

Tab Key, Tab to the next selectable item (the browser handles this by default)

Not quite, the browser is not restricting focusables to the dialog, and you have to use a thing called FocusLock or FocusTrap to keep focus within the Modal, to make it modal.

Use focus-lock for this - there are dom, react and vue ports of the library.

In the same time, you also have to disable page scroll, but that's another story.

link2twenty profile image
Andrew Bone Author

I would tend to use the inert polyfill but was aiming to avoid adding external JS. I will add a caveat to the article 😊

rhymes profile image

Congrats for the new job Andrew, awesome post as always!

link2twenty profile image
Andrew Bone Author

Thanks 😁