Bruce Lawson’s personal site

Modal dialogues in HTML5

A major cause of accessibility problems in Web Apps is authors faking modal dialogue boxes and not providing keyboard access to close or respond to those. Thanks largely to the agitation of The Mighty Steve Faulkner, Ian Hickson will be looking at at how to build this into the language.

This is particularly welcome, because when I interviewed Ian for the Web Standards Project two years ago, I asked him what his favourite feature that will get bumped from HTML5 to HTMLnext, and he replied

In-window modal dialogs or dialog box—the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say "Save As…" is usually a modal dialog.

Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say "make this section a modal dialog". Like showModalDialog(), but within the page instead of opening a new window with a new page.

I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Steve’s mail to the working group gives lots of examples of faked modal dialogues in the wild. They’re also collecting use-cases over at the WHATWG wiki – don’t be bashful to add any that you can think of.

It would be super if there were a declarative method, for example (off the top of my head) a modal attribute that could go on a div/ article/ form that would do the trick.

What do you think?

16 Responses to “ Modal dialogues in HTML5 ”

Comment by alain

Problem is, in my opinion, people “have” to use fake dialogs and windows, because they simply want to bypass the user, in order to show advertising in most cases.
The proper dialog would be great, but would it be used ?
A proper component for a proper use would be great indeed !

Comment by steve faulkner

@alian, I don’t think the majority of cases are anything to do with wanting to “bypass the user” though with any feature there are people who will want to misuse it.

Comment by Stuart Bates

This would be a great addition – the reason my designers create custom modals for confirmations is simply the current inability to style them. And I’ve just checked none of them have keyboard shortcuts… I’ll be having words!

Comment by AlastairC

It would be good to have it baked in, but where?

Given that these things are inherently dynamic, HTML may not be the right place. I.e. you generally don’t load a page with a modal dialogue in place, it is a reaction to an event on the page.

Bruce’s suggestion feels appropriate from an ARIA point of view, where that attribute is dynamically added to a container that is created or un-hidden.

The only other suggestion I can think of might be to apply something to the link/event that calls the dialogue, as that might make the interaction smoother. (I’m totally guessing about that, it’s just an idea!)

Comment by Bruce

Good point Alastair.

What about <div hidden aria-hidden=true modal>

So it’s hidden but the modal attribute pops it up when its unhidden (or something)?

TOMA, of course

Comment by steve faulkner


Given that these things are inherently dynamic, HTML may not be the right place. I.e. you generally don’t load a page with a modal dialogue in place, it is a reaction to an event on the page.

as you know there are 2 ways that UI widgets such as dialogs/overlays/lighboxes are displayed, either by adding HTML to the DOM or by changing the CSS display property in response to user interaction. I don’t see how either of these preclude the addition of an attrbute to indicate the resulting HTML subtree of a specificed element is to be treated as modal.

It could simply be that when an element with a CSS display value!=none has a modal attribute then the behaviors associated with modality are applied by the browser.

btw modal is not being suggested as a role but as an indication of state that infers certain properties on the element and its children.

Comment by Carlos C Soto

Modal dialogs would be one of the best things that could happend to HTML5. Please, remember that web applications are increasing and not only webpages. I mean, ERP, CRM, HRM, etc.. and these kind of applications would have a huge benefit from modal windows (or elements).

The main problem in modal windows right now is that when the user is using tabs then he cannot access any of the other tabs (but can access to other windows), also that Google Chrome is not supporting it.

The main problem with modal elements is the classic approach: display a layer with zIndex to block the access to lower elements. In this model the user can access the lower elements by simply pressing tab key, also this method not always work as you want. The other problem with this approach is that there are not a returnValue from the modal element.

A modal dialog has three excelent properties:
1. The caller process waits until the modal dialog is closed.
2. Another browser thread is created and you can navigate apart the caller window
3. The opportunity to return a value

I hope modal dialogs can be included in the final HTML5 spec. It would be great that the problem to access other tabs in the same navigation window could be solved and request to all major browsers to support the standar.

See “showModalDialog” at

Comment by Jason Grant

I suppose there are (at least) 2 types of modal windows I can think of.

One is the ‘alert’ window which stops me from progressing in order to save or confirm something which usually contains a simple message and 1 or 2 buttons to select.

Another type of modal window would be something along the lines of what FaceBook uses for browsing pictures on there or what Twitter desktop browser version uses when sending a direct message to someone (i.e. a modal window which is a mini-app in itself).

I think HTML5 should cater for both of these as there are solid, well known and increasingly more frequent use cases that need both of these types of features in HTML5 and modern browsers via a simple one liner.


Comment by AlastairC

Hi Steve,

You’re probably right, I’m just thinking around the backwards compatibility.

Assuming some browsers don’t know about ‘modality’ in whatever form it takes, it needs to still work, but without some enhancements. (Or with those enhancements applied by JS manually.)

The reasons I thought it might be best applied via an event on a link was that you might have several ‘modal’ dialogues hidden. If the link causes a modal dialgue, it makes sense (to me) that it triggers the change to modal, rather than something applied in static HTML to several divs.

Oh, and for the modal-dialogue enthusiasts, there are some good reasons why they can be problematic for everyone, so use with care…

Comment by Mike

Surely the correct thing to do is actually get a new JavaScript function – the main reason that people don’t just use Alert(), confirm() is the lack of styling – make a fourth type that accepts HTML elements and everyone will be happy – no need to muck about with the HTML itself.

Comment by Dave Hodder

The key advantage of reusing showModalDialog() is of course support in older browsers, going all the way back to IE4 and Firefox 3. A disadvantage is that it looks rather ugly, compared to the funky dialogues jQuery UI et al. have on offer.

If you compare and contrast the display of window.alert() between Firefox 3.6 and Firefox 4.0, you’ll see it’s changed from being a window-modal dialogue to a tab-modal dialogue which greys out the content its opening tab. Personally I think it’s a great usability improvement… and if showModalDialog() did something similar, across the five main desktop browsers, it would see a lot more widespread use.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.