RE: alertdialog versus dialog questions, also modal versus non-modal

Ok thanks.


Interesting in your reply was also that a defined behavior of AT was/is
presumed as part of the use case

when encountering these kind of roles, whereas there is no separate
"Best Practices for AT" document available yet covering these cases.


I feel that this is still a gap bringing some lugubrious aspect in the
game for there is still much room for interpretation, even also for AT


So, to complete picture, on my wish list would be


1. ARIA - Best Practices for Authors

2. ARIA - Best Practices for User Agents

3. ARIA - Best Practices for Assistive Technology


Part of 3. would be e.g. rules not to suppress Alt+ArrowDown key
combinations for JS code in toolkits (for role=combobox may need an
expandable popup below that should work with recommended best practices
keyboard definitions for opening) .. generally not to suppress all key
combinations given there.


Best Regards




From: Aaron M Leventhal [] 
Sent: Mittwoch, 28. Mai 2008 12:59
To: Schnabel, Stefan
Cc: James Craig; W3C WAI-XTECH;
Subject: RE: alertdialog versus dialog questions, also modal versus


There is really no complete guide for authors yet. I agree we need that.

- Aaron 


"Schnabel, Stefan" <> 


Aaron M Leventhal/Cambridge/IBM@IBMUS, "James Craig" <> 


"W3C WAI-XTECH" <>, <> 


05/28/2008 12:54 PM 


RE: alertdialog versus dialog questions, also modal versus non-modal



I had the same question in mind. More of that kind of background info in
best practices docs related to role usage use cases, please J 
-       Stefan 
From: [
<> ] On Behalf Of Aaron M Leventhal
Sent: Mittwoch, 28. Mai 2008 11:41
To: James Craig
Subject: Re: alertdialog versus dialog questions, also modal versus

Looks like my last response didn't make it through, so I'll try again. 

It's a useful for a screen reader to know if the current container is an
alertdialog vs. a dialog. 
Typically a dialog is not read from start to end. The title, current
focus, and probably any groupbox or pane title would be read. Otherwise
you'd get quite verbose preferences dialogs. It wouldn't be useful to
read the whole thing from start to end. 

However, in many cases you don't want the user to miss the main message
of a dialog. An alertdialog is just a simple message like "Your mailbox
is full, please clean unwanted mails, Ok, button". Because the screen
reader knows it's an alertdialog is knows to read the whole thing as
soon as anything in the dialog gets focused. 

There is no way currently to indicate that a dialog is modal or
modeless. I'm not sure how a sighted person figures this out, other than
knowing from context or trying to focus outside of the dialog. If
someone can state an important reason to expose that then it should be
considered after ARIA 1.0. IIRC the group has decided not to take on new
properties since we're trying to get the spec ready for last call. 

- Aaron 


James Craig <> 




05/28/2008 01:37 AM 


alertdialog versus dialog questions, also modal versus non-modal




Apologies if this question has already been discussed, but I fail to  
see a meaningful difference in the ARIA roles for alertdialog and  
dialog. AFAIK, the only discussion of this on the xTech list is the  
following, where Al points out an implementation problem with  
@role="alert dialog"

Implementation issues aside, it seems to me that there is no  
meaningful difference between an alert dialog and a standard dialog.  
Both roles use an application window that receives focus and requires  
some form of user input or acknowledgment. If this is true, they  
should both be standard dialogs, because @role="dialog" appears to be  
just a child role of @role="alert" that also receives focus. Please  
correct me if I'm missing something in the reading or implementation.

For reference:

alertdialog <
<> >
               A separate window (may be simulated) with an alert, where
               focus goes to the window or a control within it.

dialog <
<> >
               A dialog is a small application window that sits above
the application
               and is designed to interrupt the current processing of an
               in order to prompt the user to enter information or
require a response.

The other bit that's not clear from this wording is how to achieve a  
modal versus non-modal dialog. Since dialog is "designed to interrupt  
the current processing of an application," I assume that means it  
maintains a "modal" state and intercepts all input until it is  
dismissed. Have I missed some other allowance for non-modal dialogs?

James Craig

Received on Wednesday, 28 May 2008 11:45:13 UTC