GNOME Bugzilla – Bug 533109
Orca doesn't speak alerts in Firefox
Last modified: 2009-03-10 00:04:53 UTC
Alerts should be spoken and Brailled when they appear. Other information: Alerts are not spoken automatically in Firefox 3.0. This causes problems because these alerts require user input. Since ORca doesn't tell you about them, you don't realize they are there.
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 attachment 113091 [details] 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 attachment 113830 [details] [review] 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.