Inconsistent behavior with ARIA roles of Dialog and AlertDialog

[vtsaran]

Latest snapshots of NVDA do not treat roles of Dialog and AlertDialog? according to the ARIA spec.
We have put together a test page where you can verify the behavior we currently get with NVDA.
http://public.yahoo.com/~kloots/ariadialog.html

[kloots]

Thanks Victor for filing this bug. Just wanted to introduce myself - I am Todd Kloots and I worked closely with Victor to put together the ARIA dialog example. Feel free to contact me if you have any questions or feedback on the ARIA dialog example provided for the bug report. If there is any additional information that I can provide to help I would be happy to do so.

Thanks,
Todd

Replying to vtsaran:

Latest snapshots of NVDA do not treat roles of Dialog and AlertDialog? according to the ARIA spec.
We have put together a test page where you can verify the behavior we currently get with NVDA.
http://public.yahoo.com/~kloots/ariadialog.html

[jteh]

Sorry for taking so long to respond on this issue. We did examine it briefly, but I wanted to give it a more thorough investigation. Many thanks for your very thorough test case.

!dialog:

• The reason that NVDA doesn't read the dialog role when the dialog is activated is because focus ancestors are not read when the virtual buffer is being used to browse the document.
• In addition, NVDA uses its virtual buffer when this dialog appears
• I would argue that an AT should never try to treat a dialog as a document. That is, an AT should not use its virtual buffer (or caret simulation in Orca's case) to read the dialog.
  • Currently, the only documented way to enforce such treatment is to use a role of application on the body.
  • However, this use case proves that there is a need to treat other roles beneath the body as applications instead of documents.
  • This needs to be discussed with the ARIA community so that an acceptable solution can be found.

!alertDialog:

• Gecko does not seem to provide a different role for alert and alertDialog. As far as I can tell, alertDialogs have a role of alert.
  • A bug should probably be filed against Gecko regarding this. I notice that Thunderbird presents alertDialogs as alerts as well.
  • As an aside, I'm not sure i see the point of an alertDialog. To me, it'd make more sense for it to be a dialog with some sort of state indicating that the information is an alert for the user. That is, the control should be *treated* like a normal dialog, but we're just telling the user that it is important. An alert is different because it doesn't receive focus, so it must be treated differently. Perhaps I should raise this as an issue with the ARIA community.
• I notice that the OK button is not a child of the alertDialog. Is there a reason for this? It seems that the controls in the dialog are children, but not in the alertDialog. Alternatively, I might be looking at the wrong object...
• The reason NVDA is reading "edit" for the alert message is that it is simply reading all descendant objects, which includes the leaf text node containing the message. These have a role of text, which normally translates to a role of edit.
  • We need to improve our reading of alerts to fix this.
  • Note that if alertDialogs are treated as dialogs, this alert event will be ignored anyway and it will instead be up to the code that retrieves dialog text.

[jteh]

Replying to jteh:

* The reason NVDA is reading "edit" for the alert message is that it is simply reading all descendant objects, which includes the leaf text node containing the message. These have a role of text, which normally translates to a role of edit.
* We need to improve our reading of alerts to fix this.

I've opened #248 to address this.