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

Improve reading of alerts #248

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 3 comments

Comments

Projects
None yet
2 participants
@nvaccessAuto

nvaccessAuto commented Jan 1, 2010

Reported by jteh on 2008-12-04 12:41
When an IAccessible alert event is fired, NVDA simply speaks the object and all its descendants. For Mozilla, this means that text can be read multiple times because of Gecko's text leaf nodes. Also, the role of all of the textual content will be read, which is not ideal.

Because alerts already use the IAccessible Dialog NVDAObject, the dialog text (retrieved by getDialogText) is alredy contained in the description property. Therefore, the alert event simply needs to:

  1. Speak the alert object, which will include its dialog text.
  2. Speak all focusable children. This will include all actions available to the user and is necessary because alerts do not receive focus.
    Blocking #160
@nvaccessAuto

This comment has been minimized.

nvaccessAuto commented Jan 1, 2010

Comment 1 by jteh on 2008-12-05 02:08
I've implemented this in the dialogTextWork bzr branch. Feedback welcome.

@nvaccessAuto

This comment has been minimized.

nvaccessAuto commented Jan 1, 2010

Comment 2 by jteh on 2009-03-10 12:07
Err... this was implemented in r2569.
Changes:
State: closed

@nvaccessAuto

This comment has been minimized.

nvaccessAuto commented Jan 1, 2010

Comment by jteh on 2009-04-01 08:27
(In #160) 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.

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