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

hi Ted,

your wrote:

"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."


my concern is that not providing a method to dismiss a dialog that cannot be
overidden by the developer may lead to situations where devious developers
will use this to force users to press a button in the dialog.

esc can be used to dismiss javascript alert/confirm/prompts I am unsure
whether this behaviour can be overidden by the author.

In regards to the ARIA mapping for dialog shouldn't the alertdialog (
http://www.w3.org/TR/wai-aria/roles#alertdialog) role also be allowed?

regards
Steve


On 9 August 2011 20:08, Edward O'Connor <eoconnor@apple.com> wrote:

> 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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html