[Bug 10645] Add a modal element, or attribute, to html5 to indicate a modal segment of the DOM (modal dialog)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10645


Shelley Powers <shelleyp@burningbird.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shelleyp@burningbird.net




--- Comment #4 from Shelley Powers <shelleyp@burningbird.net>  2010-09-18 13:17:45 ---
(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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 18 September 2010 13:17:48 UTC