472311 - Alert dialogs not being spoken, section 508 issue

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[Aaron Leventhal]

Currently JS dialogs are not read by JAWS. They're telling us it would work correctly if we used ROLE_DIALOG instead of ROLE_ALERT.

They also said they are not expecting to see ROLE_ALERT for any dialog ever. We're using that for ARIA role="alertdialog" as well. This is similar to what James was saying on free-aria.

Basically we need to figure out what we're doing here, and try to get it working with current screen readers.

Comment 1

[Marco Zehe (:MarcoZ)]

I gave this some thought when it was mentioned to me some time ago. While I do not have a definitive answer for ARIA alertdialogs--and this seems to be a point of general uncertainty again and again--, I do have an opinion about JS dialogs. For all intents and purposes: These are dialogs. They bring up a modal window, they focus an OK button, or they put focus into a textbox if it's an input, not an alert function, and in all other rrespects: This thing is a dialog.

I would suggest we change the binding appropriately. This would allow JAWS and other screen readers to read the static text automatically, be it the alert message or the prompt for the input.

Comment 2

[James Teh [:Jamie]]

free-aria thread:
http://groups.google.com/group/free-aria/browse_thread/thread/555f8a92099d9b45

I agree with Marco. Note that Thunderbird brings up error dialogs which also get a role of alert; I assume this is similar to JS dialogs.

Following on from Marco's comments, I'd argue that alertdialogs are just dialogs - they set focus to an OK button like any standard message box.

As I noted on free-aria, the algorithm to retrieve the dialog message text can be inaccurate and could possibly miss information. However, I'd argue that the correct solution for this problem is to find a way of communicating which elements specify the caption for the dialog, rather than simply using the alert role to mean "read all descendants".

Comment 3

[Marco Zehe (:MarcoZ)]

Jamie, is NVDA using the accessibleDescription of a dialog accessible to read the dialog text? If we make sure that the appropriate text becomes the accDescription, would that help you?

Comment 4

[James Teh [:Jamie]]

(In reply to comment #3)
> Jamie, is NVDA using the accessibleDescription of a dialog accessible to read
> the dialog text?
No. We override the description using our own algorithm to retrieve dialog text from specific descendants. Standard Windows dialogs do not set accDescription appropriately, so we can't use that in most cases.

> If we make sure that the appropriate text becomes the
> accDescription, would that help you?
I'm guessing that Mozilla probably has a better idea of the "appropriate" text than we do, so this does make sense. We would then check for a valid accDescription on a dialog and use that if it exists instead of our own algorithm. Mick, would you agree?

Note that this *may* cause double speaking for some screen readers, so it should be tested with them also.

Comment 5

[Michael Curran]

(In reply to comment #4)
Jamie: It is fine by me if we do not override accDescription if the dialog provides something sane. I don't know if it will be enough though just to do this if accDescription contains something, in NVDA we may need better rules. 
But in regards to Gecko putting the caption in accDescription, I think this is a great idea.
In fact, I would like to see a describedBy relation between the dialog and the caption labels, and I believe that Gecko accessibility will automatically do the accDescription thing for free.

Comment 6

[Aaron Leventhal]

Here's the plan:
1. expose ARIA alertdialog and JavaScript message boxes as ROLE_DIALOG
2. have a describedby/accDescription on the dialog object, pointing to what needs to be spoken when dialog appears

Will this work for NVDA?

Comment 7

[James Teh [:Jamie]]

Yes, this will work for NVDA. Thanks.

Note that we can't/don't currently handle accDescription on dialogs, but we can fix this.

Any chance of exposing accDescription/describedBy for alerts as well? I can open a new bug if needed. I figure it would make sense to do this for both dialogs and alerts, given their similarities.

Comment 8

[Aaron Leventhal]

James, are you talking about in page alerts that don't get focused? The ones where we file EVENT_ALERT and they currently work in all the screen readers?

I don't really want to touch those. What's the point in using describedby when everything inside them needs to be spoken, by definition?

Comment 9

[Aaron Leventhal]

We need this for our JavaScript alerts to be accessible.

Comment 10

[Aaron Leventhal]

ARIA alert dialog test cases: http://developer.yahoo.com/yui/examples/container/container-ariaplugin_clean.html

Comment 11

[Marco Zehe (:MarcoZ)]

Attachment: Patch

1. In ARIA map, change exposed role of alertdialog to ROLE_DIALOG from ROLE_ALERT.
2. In the common dialog, remove the role of "alert" since this is an ordinary dialog in all its use cases, and add an aria-describedby attribute pointing to the element that always contains the information text.

Results so far with NVDA and JAWS with a JS dialog:
1. NVDA reads the dialog title plus text, plus the focused button for JS dialogs.
JAWS reads the title, the word "Description: ", followed by the dialog text, and the focused OK button.

Comment 12

[Marco Zehe (:MarcoZ)]

More results:
1. Window-Eyes does not read the title or text of the JS alert regardless of the role. Neither alert nor dialog causes it to speak anything other than the "OK" button.

On the ARIA ALERTDIALOG:
1. JAWS identifies these as dialogs with this patch. However, its virtual buffer does not update to show anything other than the dialog title. So the form or the "Your changes have been saved" messages don't show up in the virtual buffer, and an Insert+Escape does not help.
Without this patch, only Dialog 3 works to some extent, JAWS picks up the fact that it's an alert and reads the message, but doesn't show it in the virtual buffer, either.
2. NVDA does not identify the ARIA dialog as such, and it doesn't read the "Your changes have been saved" message automatically, but it sees it in its virtual buffer, and it also sees the forms of Dialog1 and Dialog2. No difference between before and after the patch.
3. Window-Eyes treats every showing of the dialog as a complete page reload. It sees all content, but it does not identify any of the dialogs as such, and also when testing before the patch, does not do anything special with the alerts. No difference in behaviour is noticed.

Comment 13

[James Teh [:Jamie]]

(In reply to comment #8)
> James, are you talking about in page alerts that don't get focused? The ones
> where we file EVENT_ALERT and they currently work in all the screen readers?
Yes.

> I don't really want to touch those.
I understand - "if it ain't broke, don't fix it." Having said that, NVDA currently extracts the captions from alert dialogs with no problems, but accDescription/describedBy was suggested to make it more accurate.

> What's the point in using describedby when
> everything inside them needs to be spoken, by definition?
Not everything. For example, we have to guard against reading the text leaf nodes. NVDA currently uses its dialog caption text algorithm to get the description and then reads all focusable children.

Comment 14

[James Teh [:Jamie]]

(In reply to comment #11)
> 1. NVDA reads the dialog title plus text, plus the focused button for JS
> dialogs.
Note that NVDA is using its own algorithm to gather dialog text here - it isn't using accDescription. We need to modify NVDA to do this.

> JAWS reads the title, the word "Description: ", followed by the dialog text,
> and the focused OK button.
JAWS can't handle the special use that Mozilla invented for accDescription. Since JAWS isn't ignoring the dialog's accDescription, I'm actually surprised it isn't reading the dialog text twice, once from the description and once from its own algorithm. Unfortunately, this probably means that if the accDescription code is removed, JAWS still won't pick up the dialog text, which is odd.

Comment 15

[James Teh [:Jamie]]

(In reply to comment #12)
> 1. JAWS identifies these as dialogs with this patch. However, its virtual
> buffer does not update to show anything other than the dialog title.
I'd argue that alert dialogs shouldn't ever be included in the virtual buffer; i.e. they should be treated like the "application" role. I made this argument on free-aria some time ago. Note that NVDA doesn't yet implement this.

Comment 16

[Marco Zehe (:MarcoZ)]

(In reply to comment #14)
> (In reply to comment #11)
> > JAWS reads the title, the word "Description: ", followed by the dialog text,
> > and the focused OK button.
> JAWS can't handle the special use that Mozilla invented for accDescription.
> Since JAWS isn't ignoring the dialog's accDescription, I'm actually surprised
> it isn't reading the dialog text twice, once from the description and once from
> its own algorithm. Unfortunately, this probably means that if the
> accDescription code is removed, JAWS still won't pick up the dialog text, which
> is odd.

It may not apply its algorithm because it found the accDescription. In other words, if there was no accDescription, it may try to read the dialog text.

Comment 17

[James Teh [:Jamie]]

(In reply to comment #16)
> > Since JAWS isn't ignoring the dialog's accDescription, I'm actually surprised
> > it isn't reading the dialog text twice, once from the description and once from
> > its own algorithm.
> It may not apply its algorithm because it found the accDescription. In other
> words, if there was no accDescription, it may try to read the dialog text.
This is possible and is the way I intended to implement it in NVDA. Still, the "description: " thing is an issue. We had to implement Gecko specific code to prevent this.

Comment 18

[Marco Zehe (:MarcoZ)]

Tha treminds me that I wanted to ask why we insert "Description: " in accDescription at all. Aaron, what's the history with this, and are the reasons still valid?

Comment 19

[James Teh [:Jamie]]

(In reply to comment #18)
> Tha treminds me that I wanted to ask why we insert "Description: " in
> accDescription at all.
Mozilla uses accDescription to communicate other information such as group position information. This was necessary before IA2. For example, on a tree view item, you might see:
"L1, 167 of 167"
The "description:" prefix indicates that this is *really* a description.
Unless JAWS uses IAccessible2 groupPosition, this is probably (and very sadly) still required.

Comment 20

[Marco Zehe (:MarcoZ)]

Jamie, thanks for the heads-up. Yes, that's still required for those screen readers (not just JAWS) that don't use IA2's groupPosition info yet.

Comment 21

[Marco Zehe (:MarcoZ)]

Try-Server builds appear here:
https://build.mozilla.org/tryserver-builds/2009-01-13_03:[e-mail]-bug_472311_JS_alerts_and_ARIA_alertdialogs_MarcoZ/

Comment 22

[Aaron Leventhal]

Jamie wrote:
> I understand - "if it ain't broke, don't fix it." Having said that, NVDA
> currently extracts the captions from alert dialogs with no problems, but
> accDescription/describedBy was suggested to make it more accurate.

Jamie, I thought you were asking for describedby in ordinary alerts.
To clarify what we're doing here:
For alertdialog, exposed with ROLE_DIALOG, we definitely will use describedby, to help NVDA know what to speak
For a normal alert, exposed with ROLE_ALERT and EVENT_ALERT, we won't use describedby. A screen reader should speak everthing inside the alert. Yes, there is an exception with text leaf nodes. We have those in there for pre-IA2 screen readers.

Comment 23

[James Teh [:Jamie]]

(In reply to comment #22)
> Jamie, I thought you were asking for describedby in ordinary alerts.
I was.
> For alertdialog, exposed with ROLE_DIALOG, we definitely will use describedby,
> to help NVDA know what to speak
Our algorithm can already usually determine what to speak for both alerts and dialogs, but we figure Mozilla will be more accurate, hence the desire for describedBy.
> For a normal alert, exposed with ROLE_ALERT and EVENT_ALERT, we won't use
> describedby. A screen reader should speak everthing inside the alert.
This is not how we handle alerts. We used to do it this way, but it led to double speaking. Now we use our normal dialog text gathering algorithm and then speak all focusable children.
> there is an exception with text leaf nodes.
Without special case code in our dialog text gathering algorithm, we can't ignore these, hence the method we now use.
> We have those in there for pre-IA2
> screen readers.
I understand and accept this.

I'm suggesting that alerts and dialogs are both the same except for the fact that we want to read focusable children for alerts. They both have a caption, so I'm suggesting they should both get describedBy for consistency. If it is difficult to do this for alerts or if it breaks other screen readers, that's fine - the current situation works ok.

Comment 24

[Aaron Leventhal]

Maybe we should chat about this on IRC. We're not understanding each other.

When I say read everything in the alert, or in a given subtree, I don't mean to read the text leaf nodes. Just consider those like the vestigial toes on a whale.

Comment 25

[Marco Zehe (:MarcoZ)]

Comment on attachment 356696 [details] [diff] [review]
Patch

Asking Enn for review of the toolkit part. Neil, I know you don't like ARIA attributes in XUL, but this is just so darn simple that you can't ignore the goodness of it. :-) One line to give AT vendors functionality without having to change any code.

Comment 26

[Neil Deakin]

Comment on attachment 356696 [details] [diff] [review]
Patch

Similar as the other bug.

Comment 27

[Marco Zehe (:MarcoZ)]

Pushed in changeset:
http://hg.mozilla.org/mozilla-central/rev/19e814487afb

Comment 28

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090202 Minefield/3.2a1pre

Comment 29

[Marco Zehe (:MarcoZ)]

Pushed to m-1.9.1 in changeset:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e171fe293271

Comment 30

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381