W3C home > Mailing lists > Public > public-html@w3.org > August 2011

Re: ISSUE-133 modal-attribute - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Edward O'Connor <eoconnor@apple.com>
Date: Tue, 09 Aug 2011 12:08:54 -0700
To: public-html@w3.org
Message-id: <m262m6pfll.fsf@eoconnor.apple.com>

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.

Received on Tuesday, 9 August 2011 19:09:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:16 UTC