When an ARIA alert is made visible, JAWS speaks it twice. This is because we expose the contents in the name.

I am having the same problem with Orca. I am using the object:children-changed:add event to detect the insertion of the alert. The following is a list of object events as seen by Accerciser for a single tooltip event: object:text-changed:delete(0, 19, ) source: [invalid | ] application: [application | Minefield] object:property-change:accessible-name(0, 0, tooltip on a button) source: [invalid | ] application: [application | Minefield] object:text-changed:insert(0, 19, tooltip on a button) source: [invalid | ] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [invalid | ]) source: [invalid | ] application: [application | Minefield] object:children-changed:remove(0, 0, [invalid | ]) source: [invalid | ] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [invalid | ]) source: [invalid | ] application: [application | Minefield] object:children-changed:remove(0, 0, [invalid | ]) source: [invalid | ] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [document frame | Dojo Tooltip Widget Test]) source: [heading | ] application: [application | Minefield] object:children-changed:remove(0, 0, [heading | ]) source: [document frame | Dojo Tooltip Widget Test] application: [application | Minefield] object:property-change:accessible-name(0, 0, tooltip on a button) source: [alert | tooltip on a button] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [section | ]) source: [alert | tooltip on a button] application: [application | Minefield] object:children-changed:add(0, 0, [alert | tooltip on a button]) source: [section | ] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [section | ]) source: [alert | tooltip on a button] application: [application | Minefield] object:children-changed:add(0, 0, [alert | tooltip on a button]) source: [section | ] application: [application | Minefield] object:property-change:accessible-parent(0, 0, [document frame | Dojo Tooltip Widget Test]) source: [heading | ] application: [application | Minefield] object:children-changed:add(0, 0, [heading | ]) source: [document frame | Dojo Tooltip Widget Test] application: [application | Minefield] The first thing I notice is the shear number of events. Are they all needed? The cause of my double announcement problem is the two object:children-changed:add(0, 0, [alert | tooltip on a button]) events.

The tooltip example at http://test.cita.uiuc.edu/aria/tooltip/html.php?title=Tooltip%20Example%201&ginc=includes/tooltip1.inc&gcss=css/tooltip1.css&gjs=js/tooltip1.js,../js/enable.js,../js/globals.js acts differently. It triggers an object:children-changed:add when the tooltip appears and another *add* event when the tooltip disappears. The dojo examples do two add events when the tooltip appears. dojo uses wairole:alert while the other example uses wairole:tooltip. An interesting point is that the dojo object:children-changed:add event points to the wairole:alert object while the UIUC example object:children-changed:add event points to a textfield with the wairole:tooltip being a child of that textfield.

Comment on attachment 274961 [details] [diff] [review] Do not compute name from descendents for ARIA alerts, also remove old #ifdef'd out code for XUL alerts since we now know 100% we don't want/need the computed name Patch looks good to me. I tested on JAWS and WE with the Mozilla XHTML alert test and with dojo tooltips.

Comment on attachment 274961 [details] [diff] [review] Do not compute name from descendents for ARIA alerts, also remove old #ifdef'd out code for XUL alerts since we now know 100% we don't want/need the computed name Needed for quality ARIA support and Dojo a11y.

Scott, I can't remember if the tooltip issue went away or not -- could you take a look at tomorrow's build and see if a follow-up bug needs to be filed for your issue?