W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

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

From: <bugzilla@jessica.w3.org>
Date: Sat, 18 Sep 2010 13:32:52 +0000
To: public-html-a11y@w3.org
Message-Id: <E1OwxXA-0007Go-TS@jessica.w3.org>

--- Comment #5 from Everett Zufelt <everett@zufelt.ca>  2010-09-18 13:32:52 ---
(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

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.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Saturday, 18 September 2010 13:32:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:44 UTC