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

Hi James,

You have a point about being able to achieve the same affect as 
alertdialog by using dialog with describedby. It's worth a discussion. We 
could file an issue for that to see what the pros/cons of changing it are.

Regarding aria-disabled on a descendant, and whether that would override 
what the ancestor had for aria-disabled --yes it could be used to 
override. As I see it we can clarify this but it's not 100% necessary. If 
override is not possible then it would not even be useful to be able to 
specify the attribute on the descendant once it was on an ancestor. In 
general, any time that two elements in an ancestor chain specify the same 
attribute, the local one is more specific for its subtree. That's just a 
general rule even outside of ARIA. As an example, if you style a paragraph 
as bold you can still restyle it to normal for any island of content 
within that paragraph.

Regarding using disabled to indicate modal -- I wouldn't want to reuse 
aria-disabled for dealing with modal vs. not modal. For me, it's related 
but not the same, and I wouldn't have thought of the connection. In any 
case, for some models, disabled items are still focusable.  What's the use 
case of knowing modal vs. not modal for a11y tools?

- Aaron



From:
James Craig <jcraig@apple.com>
To:
Aaron M Leventhal/Cambridge/IBM@IBMUS
Cc:
W3C WAI-XTECH <wai-xtech@w3.org>
Date:
06/09/2008 07:26 AM
Subject:
Re: alertdialog versus dialog questions, also modal versus non-modal




Aaron M Leventhal wrote:

> It's a useful distinction for a screen reader.
> A screen reader may automatically read from start to end for an 
> alertdialog, but for a dialog just read the dialog title and current 
> focus chain (including pane or groupbox names for example).

After completely rereading the latest draft, I am still unconvinced 
that there needs to be a separate role for dialog and alertdialog. 
What if an alertdialog was just a dialog that referenced its alert 
message contents in the describedby property? If a dialog has a 
describedby property, then both the label and description are spoken 
when the dialog is displayed. Otherwise, it's just a regular dialog 
and only the label is spoken.

> As far as modal vs. nonmodal, we would need to add an ARIA property 
> or special role to make the distinction.

After further thought, it seems like you could do it by having a 
dialog that was the only non-disabled element in the DOM. This might 
bring up the issue though, of how aria-disabled is inherited. Right 
now it's worded, "The state of being disabled applies to the current 
element and all focusable descendant elements of the element on which 
the disabled state is applied."

It is not clear though, what should happen if I were to set aria- 
disabled="false" on a descendant of a disabled element. Would that 
descendent be enabled, or would it be overridden by its ancestor's 
disabled state?

Depending on that answer, here are two markup possibilities for "modal 
dialogs"

Possibility 1:

<div role="main" aria-disabled="true">
                 <!-- all body contents are disabled -->
</div>
<div role="dialog">
                 <!-- modal dialog is not a descendent of the disabled 
element -->
</div>


Possibility 2:

<div role="main" aria-disabled="true">
                 <!-- all body contents are disabled except for the dialog 
-->
                 <div role="dialog" aria-disabled="false" >
                                 <!-- modal dialog is an enabled 
descendent of the disabled element -->
                 </div>
</div>