I like this idea, +1

Suggest: 

1. User Agents must provide a device agnostic mechanism to dismiss the modal.
2. User Agents should return focus to the element from which the modal was
activated upon its dismissal.

better not to leave it to authors...

(In reply to comment #0)
> Issue:
> 
> html5 does not currently specify a mechanism to indicate that a segment of the
> DOM is modal.
> 
> Modal dialogs are common in many desktop and web UI toolkits.  It is currently
> possible to create modal dialog behaviour using CSS, Javascript, and WAI-ARIA. 
> It is not, however, easy to create a robust modal dialog using these compatible
> technologies.
> 
> Proposal:
> 
> (Normative)
> 
> 1. Add a modal element or attribute ("modal") to the html5 specification.
> 
> 2. When a modal is present in the DOM UAs must treat the modal and its children
> as a modal segment of the DOM.
> 
> 2.1 UAs must constrain input / interaction events (e.g. keyboard and mouse) to
> the modal and its children.
> 
> 2.2 UAs must map only the modal and its children to the accessibility tree.
> 
> 3. If focus has not been explicitly set to a child of the modal, UAs must set
> focus to the first focusable child of the modal.
> 
> (Informative)
> 
> 4. Authors must provide a device agnostic mechanism to dismiss the modal.
> 
> 5. Authors should return focus to the element from which the modal was
> activated upon its dismissal.
> 
> Resources:
> 
> Definition
> 
> Modal window - Wikipedia, the free encyclopedia
> http://en.wikipedia.org/wiki/Modal_window
> 
> Implementations of web UI modal dialogs
> 
> Cutting Edge: Modal Dialog Boxes with AJAX
> http://msdn.microsoft.com/en-us/magazine/cc164247.aspx
> 
> Drupal 7 Overlay (core module to display administrative pages).
> http://api.drupal.org/api/drupal/modules--overlay--overlay.module/7
> 
> jQuery UI - Dialog Demos & Documentation
> http://jqueryui.com/demos/dialog/
> 
> YUI 2: SimpleDialog
> http://developer.yahoo.com/yui/container/simpledialog/
> 
> Best practices for accessible modal dialogs
> 
> WAI-ARIA Authoring Practices 1.0: 3.3 Making a Dialog Modal
> http://www.w3.org/TR/wai-aria-practices/#dialog_modal
> 
> DHTML Style Guide | dev.aol.com: 8. Dialog (Modal)
> http://dev.aol.com/dhtml_style_guide#dialogmodal

(In reply to comment #2)
> Suggest: 
> 
> 1. User Agents must provide a device agnostic mechanism to dismiss the modal.
> 2. User Agents should return focus to the element from which the modal was
> activated upon its dismissal.
> 
> better not to leave it to authors...

I would be content with either proposal for dismissal of the modal.  However, if we have uAs responsible for dismissal of the modal we need an event mechanism to fire at the modal so that the application can perform cleanup.  If authors are responsible for dismissal (as they are now with non-native modals) they can handle any necessary cleanup in their custom close handler.

(In reply to comment #0)
> Issue:
> 
> html5 does not currently specify a mechanism to indicate that a segment of the
> DOM is modal.
> 
> Modal dialogs are common in many desktop and web UI toolkits.  It is currently
> possible to create modal dialog behaviour using CSS, Javascript, and WAI-ARIA. 
> It is not, however, easy to create a robust modal dialog using these compatible
> technologies.
> 
> Proposal:
> 
> (Normative)
> 
> 1. Add a modal element or attribute ("modal") to the html5 specification.
> 
> 2. When a modal is present in the DOM UAs must treat the modal and its children
> as a modal segment of the DOM.
> 
> 2.1 UAs must constrain input / interaction events (e.g. keyboard and mouse) to
> the modal and its children.
> 
> 2.2 UAs must map only the modal and its children to the accessibility tree.
> 
> 3. If focus has not been explicitly set to a child of the modal, UAs must set
> focus to the first focusable child of the modal.
> 
> (Informative)
> 
> 4. Authors must provide a device agnostic mechanism to dismiss the modal.
> 
> 5. Authors should return focus to the element from which the modal was
> activated upon its dismissal.
> 
> Resources:
> 
> Definition
> 
> Modal window - Wikipedia, the free encyclopedia
> http://en.wikipedia.org/wiki/Modal_window
> 
> Implementations of web UI modal dialogs
> 
> Cutting Edge: Modal Dialog Boxes with AJAX
> http://msdn.microsoft.com/en-us/magazine/cc164247.aspx
> 
> Drupal 7 Overlay (core module to display administrative pages).
> http://api.drupal.org/api/drupal/modules--overlay--overlay.module/7
> 
> jQuery UI - Dialog Demos & Documentation
> http://jqueryui.com/demos/dialog/
> 
> YUI 2: SimpleDialog
> http://developer.yahoo.com/yui/container/simpledialog/
> 
> Best practices for accessible modal dialogs
> 
> WAI-ARIA Authoring Practices 1.0: 3.3 Making a Dialog Modal
> http://www.w3.org/TR/wai-aria-practices/#dialog_modal
> 
> DHTML Style Guide | dev.aol.com: 8. Dialog (Modal)
> http://dev.aol.com/dhtml_style_guide#dialogmodal


I have a couple of questions:

When you say it isn't easy to create a robust modal dialog, is it because there are so many moving parts, and it's difficult for people to get all of them correct? Or is it because the necessary ARIA functionality is currently erratically implemented by screen readers?

I'm looking at the Overlay is not Accessible bug in Drupal 7[1], and the impression I'm getting isn't that the functionality is difficult to implement, but that ARIA support among the screen readers is erratic--which could also mean that the necessary API support in the browsers is erratic, too, I don't know. 

The reason I bring this up is that if the problem is that the pieces are in place, but the screen reader implementation isn't complete, I'm not sure that adding a new HTML5 attribute will solve the problem. If the browsers use the same API to signal the modal features as they use to meet the ARIA needs, but the screen readers haven't implemented the necessary functionality yet, the problem will continue to exist. 

However, if the problem is that the implementation is there, but developers just can't combine all the pieces correctly because there's so many, then yeah, it would be better to create a declarative solution. This isn't like hidden, or even details, which are a simple to create in existing technologies--this is a much more complex behavior.
 


[1] http://drupal.org/node/716612

(In reply to comment #4)
> 
> I have a couple of questions:
> 
> When you say it isn't easy to create a robust modal dialog, is it because there
> are so many moving parts, and it's difficult for people to get all of them
> correct? Or is it because the necessary ARIA functionality is currently
> erratically implemented by screen readers?
> 
> I'm looking at the Overlay is not Accessible bug in Drupal 7[1], and the
> impression I'm getting isn't that the functionality is difficult to implement,
> but that ARIA support among the screen readers is erratic--which could also
> mean that the necessary API support in the browsers is erratic, too, I don't
> know. 
> 
> The reason I bring this up is that if the problem is that the pieces are in
> place, but the screen reader implementation isn't complete, I'm not sure that
> adding a new HTML5 attribute will solve the problem. If the browsers use the
> same API to signal the modal features as they use to meet the ARIA needs, but
> the screen readers haven't implemented the necessary functionality yet, the
> problem will continue to exist. 
> 
> However, if the problem is that the implementation is there, but developers
> just can't combine all the pieces correctly because there's so many, then yeah,
> it would be better to create a declarative solution. This isn't like hidden, or
> even details, which are a simple to create in existing technologies--this is a
> much more complex behavior.
> 
> 
> 
> [1] http://drupal.org/node/716612

I believe that there are three reasons that it is hard to get a modal dialog right.

1. The most, by far, important reason is that there is no API (in html or ARIA) to indicate that a segment of the DOM is modal.  If you refer to the best practices that I listed, there is an explanation in each of how the modal behaviour (restricting input to only the modal segment of the DOM) must be handled by the author.  I suppose this would fall into the difficult to get right category.

2. Using ARIA, if an author wishes to create a modal within a page which is not an application it is impossible to constrain users of buffered screen-readers within the modal.  This is because unless the screen-reader is in "application" mode (role="application" or role="dialog") most keyboard commands are not passed through to the browser to be constrained.

3. Lastly, different assistive technology implementations of ARIA are somewhat inconsistent.  I agree with you that this, in and of itself, is not a legitimate reason to request modal be added to html5.

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > I have a couple of questions:
> > 
> > When you say it isn't easy to create a robust modal dialog, is it because there
> > are so many moving parts, and it's difficult for people to get all of them
> > correct? Or is it because the necessary ARIA functionality is currently
> > erratically implemented by screen readers?
> > 
> > I'm looking at the Overlay is not Accessible bug in Drupal 7[1], and the
> > impression I'm getting isn't that the functionality is difficult to implement,
> > but that ARIA support among the screen readers is erratic--which could also
> > mean that the necessary API support in the browsers is erratic, too, I don't
> > know. 
> > 
> > The reason I bring this up is that if the problem is that the pieces are in
> > place, but the screen reader implementation isn't complete, I'm not sure that
> > adding a new HTML5 attribute will solve the problem. If the browsers use the
> > same API to signal the modal features as they use to meet the ARIA needs, but
> > the screen readers haven't implemented the necessary functionality yet, the
> > problem will continue to exist. 
> > 
> > However, if the problem is that the implementation is there, but developers
> > just can't combine all the pieces correctly because there's so many, then yeah,
> > it would be better to create a declarative solution. This isn't like hidden, or
> > even details, which are a simple to create in existing technologies--this is a
> > much more complex behavior.
> > 
> > 
> > 
> > [1] http://drupal.org/node/716612
> 
> I believe that there are three reasons that it is hard to get a modal dialog
> right.
> 
> 1. The most, by far, important reason is that there is no API (in html or ARIA)
> to indicate that a segment of the DOM is modal.  If you refer to the best
> practices that I listed, there is an explanation in each of how the modal
> behaviour (restricting input to only the modal segment of the DOM) must be
> handled by the author.  I suppose this would fall into the difficult to get
> right category.
> 
> 2. Using ARIA, if an author wishes to create a modal within a page which is not
> an application it is impossible to constrain users of buffered screen-readers
> within the modal.  This is because unless the screen-reader is in "application"
> mode (role="application" or role="dialog") most keyboard commands are not
> passed through to the browser to be constrained.
> 
> 3. Lastly, different assistive technology implementations of ARIA are somewhat
> inconsistent.  I agree with you that this, in and of itself, is not a
> legitimate reason to request modal be added to html5.

Thanks for the answer.

I agree with your assessment in category #3. I can respect the difficulty inherent in implementing the functionality, as you outlined in category #1, though I'm not sure it would be sufficient to override my frugal attitude when it comes to adding new attributes and elements to HTML5 (though frankly, and I'm experienced with JavaScript, I would approach coding the necessary functionality with trepidation). However, your category #2 seems to be spot on. 

I definitely noticed the problems with category #2, in your discussion in the jQuery forum[1]: that this issue is beyond just being difficult to implement; that there are deficiencies, or gaps if you will, in the existing technologies to implement all that is necessary in order to have a modal dialog experience in AT. 

In other words, signaling the existence of a modal dialog is needed functionality that can't be completely emulated with existing ARIA attributes or roles, or using JavaScript. The Drupal 7 overlay is almost a perfect use case/test case for this.

[1] http://groups.google.com/group/jquery-a11y/browse_thread/thread/3b59aa35d07d7b1f?pli=1

After some external discussion, I believe the general consensus is that this would best be expressed as an attribute, and I believe that the title of this bug should be modified to reflect this. 

References:

http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0477.html (Chaals McCathieNevile)

Summation of a back-and forth discussion between myself and Gez Lemon:
  "@johnfoliot The role is most likely to be dialog; modal is definitely not a role, but the state of the object." - Gez Lemon 
http://twitter.com/gezlemon/status/24794994527 

  "@johnfoliot I wouldn't want either: it's not a role (element or role attribute), it's a state, which should be an attribute." - Gez Lemon
http://twitter.com/gezlemon/status/24792977638
(twitter references likely to disappear in time)

Updated bug summary to reflect consensus that modal should be an attribute rather than an element.

This has long been on the list of features to add to the spec, we're just waiting for the features already added to the spec to get implemented before adding it.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments, but it's still too early.

adding tracker request, there has been non agreement by the working group that 'it's still too early' to spec a modal feature for HTML5

(In reply to comment #10)
> adding tracker request, there has been non agreement by the working group that
> 'it's still too early' to spec a modal feature for HTML5

+1

http://www.w3.org/html/wg/tracker/issues/133

I'm curious why this isn't sufficient as a modal dialog feature:

http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog

(In reply to comment #13)
> I'm curious why this isn't sufficient as a modal dialog feature:
> 
> http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog

I'm not certain what you are referring to.  The link you provided crashed my browser several times when I attempted to open it.  Would you please provide a different example, or provide the excerpt you are referring to as a quotation?

Note: Along with large pages needing to be processed by a browser, they sometimes also need to be processed by asistive technology like screen-readers (which I use).  Also, using an # anchor is hit and miss for some assistive technology as to whether you will actually end up on the correct section of the document, especially for large documents.

(In reply to comment #14)
> I'm not certain what you are referring to.  The link you provided crashed my
> browser several times when I attempted to open it.  Would you please provide a
> different example, or provide the excerpt you are referring to as a quotation?

It's Section 6.3.3 "Dialogs implemented using separate documents".

Here's the link to the same section in the multipage version of the spec:

http://dev.w3.org/html5/spec/timers.html#dom-showmodaldialog

(In reply to comment #13)
> I'm curious why this isn't sufficient as a modal dialog feature:
> 
> http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog

Why is window.alert() not sufficient.

1. although the alert() message is configurable, it is not really very configurable.  What if I want to ask for a name, phone number, e-mail address, subject and comment in the dialog?

2. What if I want users of my CMS to be able to open administrative pages as a modal dialog while keeping the context of the page from which they launched the administrative pages in the background?

3. What if I want a modal lightbox to present multimedia?

4. I do not believe that CSS can be applied to dialogs created by alert().

I am sure that there are many other use-cases and drawbacks to using alert.  This would seem to be true based on the number of UI toolkits that provide a modal dialog UI component.

(In reply to comment #16)
> (In reply to comment #13)
> > I'm curious why this isn't sufficient as a modal dialog feature:
> > 
> > http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog
> 
> Why is window.alert() not sufficient.
> 
> 1. although the alert() message is configurable, it is not really very
> configurable.  What if I want to ask for a name, phone number, e-mail address,
> subject and comment in the dialog?
> 
> 2. What if I want users of my CMS to be able to open administrative pages as a
> modal dialog while keeping the context of the page from which they launched the
> administrative pages in the background?
> 
> 3. What if I want a modal lightbox to present multimedia?
> 
> 4. I do not believe that CSS can be applied to dialogs created by alert().
> 
> I am sure that there are many other use-cases and drawbacks to using alert. 
> This would seem to be true based on the number of UI toolkits that provide a
> modal dialog UI component.

Responded to wrong section of the spec.

Why is showmodaldialog() not sufficient.

1. Requires a new browser window.

2. Can be mistaken for a popup window (since it is a new window) see:

User agents are expected to disable this method in certain cases to avoid user annoyance (e.g. as part of their popup blocker feature). For instance, a
user agent could require that a site be white-listed before enabling this method, or the user agent could be configured to only allow one modal dialog
at a time.

Thanks

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #13)
> > > I'm curious why this isn't sufficient as a modal dialog feature:
> > > 
> > > http://dev.w3.org/html5/spec/Overview.html#dom-showmodaldialog
> > 
> > Why is window.alert() not sufficient.
> > 
> > 1. although the alert() message is configurable, it is not really very
> > configurable.  What if I want to ask for a name, phone number, e-mail address,
> > subject and comment in the dialog?
> > 
> > 2. What if I want users of my CMS to be able to open administrative pages as a
> > modal dialog while keeping the context of the page from which they launched the
> > administrative pages in the background?
> > 
> > 3. What if I want a modal lightbox to present multimedia?
> > 
> > 4. I do not believe that CSS can be applied to dialogs created by alert().
> > 
> > I am sure that there are many other use-cases and drawbacks to using alert. 
> > This would seem to be true based on the number of UI toolkits that provide a
> > modal dialog UI component.
> 
> Responded to wrong section of the spec.
> 
> Why is showmodaldialog() not sufficient.
> 
> 1. Requires a new browser window.
> 
> 2. Can be mistaken for a popup window (since it is a new window) see:

That may be true but it seems to meet your originally stated requirements. Is there an additional "must not create a new browser window" requirement?

> 
> User agents are expected to disable this method in certain cases to avoid user
> annoyance (e.g. as part of their popup blocker feature). For instance, a
> user agent could require that a site be white-listed before enabling this
> method, or the user agent could be configured to only allow one modal dialog
> at a time.

In theory, yes. In practice, no - at most it gets a user gesture limitation like window.open.

http://lists.w3.org/Archives/Public/public-html/2010Dec/0122.html

Bug-triage sub-team remarks: The related ISSUE-133 has been closed without prejudice because no change proposals have been submitted, so this has not gained enough interest to be task force priority.

Working Group Decision:

http://lists.w3.org/Archives/Public/public-html/2011Dec/0053.html

Change Proposal:

http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-133

*** Bug 13239 has been marked as a duplicate of this bug. ***

Looks like this is basically a subset of: http://wiki.whatwg.org/wiki/Dialogs#Proposal

(Need to speak to Anne about integration with fullscreen API.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Accepted
Change Description: http://html5.org/r/7049-7051
Rationale: See preceding comments.