[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





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

-- 
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:52:34 UTC