- From: Edward O'Connor <eoconnor@apple.com>
- Date: Tue, 09 Aug 2011 12:08:54 -0700
- To: public-html@w3.org
Hi, Steve Faulkner wrote: > I will happily withdraw my change proposal in favout of Ted's OK. With only one proposal, we'll be able to process the issue via a CfC instead of a poll. Thanks! > a few questions Ted: > > "By default, pressing the Escape key in a dialog fires its 'cancel' > event. This can be prevented from within a 'keyup' or 'keypressed' > event handler." > > why allow the dismissal of the dialog using the esc key to be > prevented? Being able to dismiss the dialog by using the escape key is usually desired, so that's the default behavior, but there are use cases for modals in which the user needs to pick from N options where none cleanly map onto a "Cancel" action. > "In ยง3.2.7 WAI-ARIA, the language feature <dialog modal> should be > specified to have the strong native semantics equivalent to > role="dialog"" > > WAI-ARIA defines 'dialog' as > > " dialog (role) A dialog is an application window that is designed to > interrupt the current processing of an application in order to prompt > the user to enter information or require a response. " > > Do you think that this is appropriate for all the use cases? Sounds like it to me. > On dialog close where does the focus move to by default? > > Even when dialogs are NOT modal it is important that tabbing to > through all the controls in the dialog does not result in focus moving > out of the dialog. > > Can you add some text to the CP to detail this? The CP covers tabbing out of the dialog (it specifies that the rest of the document be unfocusable), though it doesn't cover how focus should behave when the dialog is closed. Because we're past the CP deadline, I'd just assume not make any edits to it at this time. Should the WG adopt the proposal, I'll file a bug for the focus-on-close issue. E. J. wrote: > We also need to ensure that authors receive guidance about the > problems that dialog / application mode, can cause for some AT users. > The keyboard interaction of AT that switches into application mode > changes significantly if the <dialog> element does not have a child > element with role="document". > > Sometimes it will be desirable to provide a true dialog (Yes, No, > Cancel), other times authors should be nesting a container with > role="document" within the dialog, to retain the expected keyboard > interaction. If the WG adopts <dialog>, could you file a spec bug on this? > It is also important that the content available to screen-readers be > restricted to the dialog's contents. This is definitely the intent of the CP, though perhaps I didn't make that sufficiently clear. As with the focus-on-close issue above, I'll file a bug on this if/when the WG adopts the proposal. Thanks, Ted
Received on Tuesday, 9 August 2011 19:09:34 UTC