Bug 533109 – Orca doesn't speak alerts in Firefox

Firefox 3 alerts occur when you submit a password -- log into any site.

Web pages can also contain alerts. Here is a sample ARIA alert:
http://www.mozilla.org/access/dhtml/alert

I think Dojo makes use of alerts.

Another use case for an alert that Orca currently does not speak:
1. Open https://bugzilla.mozilla.org.
2. Press CTRL+L to focus the Location bar.
3. Press SHIFT+TAB. Orca will speak "Verified by: Equifax Button".
4. Press SPACE.

Expected: Orca should speak all the text that appears in the popup.
Actual result: Only the button that focus lands on is spoken.

On Windows, the same kind of alert is being generated as for the "Do you want
Firefox to save this password?" alert.

As an FYI....when that funny little alert bar appears at the top of FF3, I see
a few of these events:

object:property-change:accessible-parent(0, 0, [scroll pane | ])
        source: [alert | ]
        application: [application | Minefield]

and then 1 of these:

object:children-changed:add(0, 0, [alert | ])
        source: [scroll pane | ]
        application: [application | Minefield]

So, we might be able to have some special decision logic in Orca that detects
an object of role "alert" being added to a "scroll pane" and then do something
as a result of that.

I'm not sure what to present to the user or what the interaction model should
be.  In the cases where we run into this, a new page has typically been loaded
and we might be just automatically reading the whole page.  Or, we might be
presenting the first line on the page.  Here's a note from Marco on what a
Windows screen reading solution does:

1. It interrupts whatever is speaking right now.
2. It speaks, and brailles in a "flash" message the content of the alert.
3. After it's done that, and the new page has finished loading, it
starts reading it.

So, the user gets notified via speech, starting with the word "alert"
that something important just came up. It also gets brailled in a
"flash" message that typically stays around for 5 seconds, unless a key
on the braille display is pressed which resets the timer to another 5
seconds.

The alert consists of the alert message itself("Do you want Minefield to
remember this password?"), followed by the buttons and their access keys
("Remember Alt+R, Never for this site ALT+E, Not now Alt+N, Close this
message").

Since these alerts stay for I believe at least 30 seconds, there's
enough time to press anyone of these hotkeys, or navigate to the alert
by CTRL+L and tab twice, which will focus the alert buttons.

We decided that for now that in brief verbosity mode we will speak "Alert
toolbar."  In verbose mode, we will speak "Alert toolbar" followed by the
static text information on the alert.  This will at least let the speech user
know something is there.  We will address braille issues later.

Not all alerts are in a toolbar. Some are ARIA alerts in web pages. What about
those?

Also, for the ones in the toolbar, if you're going to speak the text, it's also
helpful to speak the button label and hotkey for activating that button. It's a
lot more convenient (and discoverable) than trying to go to the location bar
and tab.

(In reply to comment #5)
> Not all alerts are in a toolbar. Some are ARIA alerts in web pages. What about
> those?

Done by Scott thanks to a MoFo grant. :-)  Same for Dojo.

Created an attachment (id=113091) [edit]
screenshot of the toolbar buttons and the keybindings exposed to us

> Also, for the ones in the toolbar, if you're going to speak the text, it's also
> helpful to speak the button label 

I'll leave that decision to our UI Guy and Project Lead.

> and hotkey for activating that button. 

Please see attached screenshot, along with 
https://bugzilla.mozilla.org/show_bug.cgi?id=440568

> lot more convenient (and discoverable) than trying to go to the location bar
> and tab.

So even if Mike and Will decide that we should indeed read the button labels,
I'm afraid users will still have to go to the location bar and Tab. :-(

Joanie, I'm remembering from the team meeting that you nolonger need any info
from me on this one.  Is that correct?  If so please feel free to take my name
off it.  

Created an attachment (id=113830) [edit]
revision 1

This patch will cause Orca to speak the word "alert" followed, in the case of a
speech verbosity setting of verbose, by the static text of the alert.  It
addresses both the "toolbar" style alert and the security alert example raised
by Marco.

Note that in the latter case, once the security alert has been displayed,
Firefox ceases to emit proper events when that alert is reshown.  Therefore, to
test this patch for that type of alert, Firefox will need to be quit and
relaunched each time.  I have opened a Mozilla bug for this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=443097

Please test.  Thanks!

Tested the patch with the Webvisum install dialog, and only the first part 
is spoken: Firefox has prevented this extension from beeing installed.
The user should be noted what to do next, namely which button should be 
pressed (including the hotkeys) to either install or reject that extension.
So further work is needed.

Hi Hermann.  Thanks for testing this!  With respect to your observations:

1. Our UI lead (Mike) indicated that we should not speak the buttons; just the
text being displayed. I could certainly change that.  However:

2. Firefox is not exposing the hotkeys to us.  See my comment #7. There's an
open Mozilla bug for that.

So.... I guess I need Mike to specify what we should do in terms of speaking
the buttons.  Then I'll make any changes that are necessary.  But even if I put
in the code to read the hotkeys, they won't be spoken until the Mozilla guys
fix their bug.

Thanks again!

This looks good as is.  If we add a training level verbosity in the future we
can address Hermann's other request at that time.  

Mike does "looks good as is" mean that you've been testing it and it seems to
work, or that the functionality I described is what you specified?

(In reply to comment #13)
> Mike does "looks good as is" mean that you've been testing it and it seems to
> work, or that the functionality I described is what you specified?
> 
both 

Okie dokie.  Thanks!  I've just checked it into trunk.  Moving to pending.