Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behavior with ARIA roles of Dialog and AlertDialog #160

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 6 comments
Closed

Comments

@nvaccessAuto
Copy link

Reported by vtsaran on 2008-08-29 18:54
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

Blocked by #248, #277

@nvaccessAuto
Copy link
Author

Comment 1 by kloots (in reply to comment description) on 2008-09-03 16:23
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

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2008-10-03 08:02
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.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh (in reply to comment 2) on 2008-12-04 12:44
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.

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2009-04-01 08:27
Now that #277 is fixed, NVDA does not use the virtual buffer at all for objects within an application (which includes dialog and alert dialog). This makes "Dialog 1" in the test case work correctly.

"Alert Dialog 1" still does not work correctly. This is because the OK button is outside the alert dialog node, which is incorrect. The button should be within the dialog in order to be classified as being part of it.

Pending further testing, I believe all of the bugs on our side are fixed.

@nvaccessAuto
Copy link
Author

Comment 5 by kloots on 2009-04-06 18:43
Cool. Since the filing of this bug, I have created a new example page that places the OK button for an alert dialog inside the alert dialog node and things seem to be working great. I tested in FF3 using NVDA 0.6p3.2. Here is a link to the example if you guys wish to test for yourselves, or use as a test case for future versions of NVDA:

http://developer.yahoo.com/yui/examples/container/container-ariaplugin_clean.html

Thanks,
Todd

Changes:
State: closed

@nvaccessAuto
Copy link
Author

Comment 6 by vtsaran on 2009-05-25 16:57
This seems to work fine as per Todd's comment above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant