Hmm...well...I'm not sure I'm seeing the events needed to let us quickly know an alert has appeared.  That is, unless we take a look at the "OK" button and then search around the hierarchy for an alert item that might be a sibling of the button.  Strangeness that I need to dig into some more.

I hope to talk with Victor about this at CSUN, which is after 2.26.  So, moving to FUTURE.

Hi Willie - 

Todd Kloots here - I work with Victor at Yahoo! and I am the author of the YUI ARIA plugins.  If there is any information that I can provide you to help with this bug, let me know.  I will also be at CSUN on Friday, in case you want to try to meet up.

- Todd

(In reply to comment #3)
> Todd Kloots here - I work with Victor at Yahoo! and I am the author of the YUI
> ARIA plugins.  If there is any information that I can provide you to help with
> this bug, let me know.  I will also be at CSUN on Friday, in case you want to
> try to meet up.

Hey Todd!  Thanks for joining in.  The problem I'm seeing is that the alert that appears with the test case in question ends up having a hierarchy I might not expect and I'm not sure we're getting the events we need.

The hierarchy looks something like this:

section
+- section (titlebar that says "Info")
+- alert (name is "Info", text is "Your changes have been saved")
   +- paragraph (" ") 
   +- form
+- button (name is "Close", but this represents the "X" in the title bar)
+- section
   +- paragraph
      +- button ("OK")

When the alert appears, focus is given to the "OK" button.

I'm not sure I'm seeing any events for the alert object when the alert appears. In bug #570550, we were able to cue off a text-inserted event for the alert, but I'm not seeing that in this case.  It's as though maybe everything is pre-created and then posted in one swoop.

The fact that we really don't get events for the alert coupled with the fact that the "OK" button is in a sibling branch, however, makes it hard for us to know the alert text has appeared.  If you can coax the YUI toolkit to spit out a text inserted event for the alert, the fix we did in bug #570550 might make the YUI alert start speaking.

Willie - 

Thanks for the detail.  As I recall I went with that hierarchy because it was the only way to get the alertdialog working in both JAWS and NVDA.  I have created a new version for you to test:

http://yuiblog.com/sandbox/yui/v270/examples/container/aria-example.html

See if that gets things working correctly in Orca.  If so, I will commit the change to the YUI ARIA plugin.

- Todd

(In reply to comment #5)
> Willie - 
> 
> Thanks for the detail.  As I recall I went with that hierarchy because it was
> the only way to get the alertdialog working in both JAWS and NVDA.  I have
> created a new version for you to test:
> 
> http://yuiblog.com/sandbox/yui/v270/examples/container/aria-example.html
> 
> See if that gets things working correctly in Orca.  If so, I will commit the
> change to the YUI ARIA plugin.

Thanks Todd!  It looks like the new example gets rid of the alert altogether and replaces it with a dialog, nesting the "OK" button in that hierarchy.  That's getting closer, but I'm not seeing the events I might look for to be notifies that the dialog has actually appeared.  All I believe I'm seeing is an event telling me the parent has changed.  An object:state-changed:showing event, for example, would be something I'd expect to get from the dialog when it appears.

Hi Willie - 

Not sure why the alert is gone now since I am still using the role of "alertdialog" on the root element of the widget.  Seems like a bug in Firefox for Linux (perhaps), since I here the role of alert being read using JAWS 10 and Firefox for Windows XP .  Here is a screen cast:

http://video.yahoo.com/watch/4627865/12374597

Regarding the event to listen for to let you know that the dialog has actually appeared:  according to the "Showing and Hiding Sections in a Widget" portion of the ARIA Best Practices document (http://www.w3.org/TR/wai-aria-practices/), you should be getting that event from the browser when the YUI Dialog toggles the CSS "display" property from "none" to "block".  

Here is the relevant snippet from the ARIA Best Practices document:
"By monitoring these behaviors a user agent may use this information to notify assistive technology that the pop-up has occurred by generating the appropriate accessibility API event."

In addition to toggling the value of the CSS "display" property, I also toggle the "aria-hidden" property to "false" when I make the alert dialog visible, as well as focus the first focusable descendant (in this case the "ok" button).  I would have to imagine that one or all three of those changes to the DOM should result in the firing of some event that allows you to know that the alert dialog is now visible.  If not, I'm not sure what else I can do, since I am doing everything exactly to the spec now.  Perhaps it would be best to consult Aaron Leventhal, or someone from Freedom Scientific to see how to get this working for Orca?  Otherwise I am kind of out of ideas, and since I am a DTML engineering, rather than a desktop software engineer, I am not sure what other advice I can provide.   Still happy to help in any way that I can though.

- Todd  

Hi Willie -

Was wondering if there was any update on this bug since my last set of feedback.  Also, wanted to let you know that I pushed the latest set of changes to the ARIA plugins live.  So, you can test those using this URL:

http://ydn.corp.yahoo.com:8374/yui/examples/container/container-ariaplugin_clean.html

- Todd

Orca master has completely re-written web support, browse + focus modes, ARIA-related fixes, etc. Plus the plugins URL is now 404ing. So closing this as obsolete. If the problem persists with Orca master, please open a new bug with updated information. Thanks!