- From: <bugzilla@jessica.w3.org>
- Date: Sat, 18 Sep 2010 13:32:52 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10645 --- 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 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. -- 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