Alert dialogs not being spoken, section 508 issue

VERIFIED FIXED

Status

()

Core
Disability Access APIs
P2
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: Aaron Leventhal, Assigned: MarcoZ)

Tracking

(Blocks: 1 bug, {access, fixed1.9.1, sec508})

unspecified
x86
All
access, fixed1.9.1, sec508
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
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

9 years ago
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".
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

9 years ago
(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

9 years ago
(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.
(Reporter)

Comment 6

9 years ago
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

9 years ago
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.
(Reporter)

Comment 8

9 years ago
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?
(Reporter)

Comment 9

9 years ago
We need this for our JavaScript alerts to be accessible.
Flags: blocking1.9.2?
(Reporter)

Comment 10

9 years ago
ARIA alert dialog test cases: http://developer.yahoo.com/yui/examples/container/container-ariaplugin_clean.html
Created attachment 356696 [details] [diff] [review]
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.
Assignee: nobody → marco.zehe
Status: NEW → ASSIGNED
Attachment #356696 - Flags: review?(aaronleventhal)
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

9 years ago
(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

9 years ago
(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

9 years ago
(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.
(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

9 years ago
(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.
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

9 years ago
(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.
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.
Try-Server builds appear here:
https://build.mozilla.org/tryserver-builds/2009-01-13_03:15-mzehe@mozilla.com-bug_472311_JS_alerts_and_ARIA_alertdialogs_MarcoZ/
(Reporter)

Comment 22

9 years ago
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.
(Reporter)

Updated

9 years ago
Attachment #356696 - Flags: review?(aaronleventhal) → review+

Comment 23

9 years ago
(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.
(Reporter)

Comment 24

9 years ago
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.
Attachment #356696 - Flags: review?(enndeakin)
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.
(Reporter)

Updated

9 years ago
Flags: blocking1.9.2? → blocking1.9.1?
Keywords: sec508
Summary: JS and ARIA alert dialogs -- what role and events to use? → Alert dialogs not being spoken, section 508 issue

Updated

9 years ago
Attachment #356696 - Flags: review?(enndeakin) → review+

Comment 26

9 years ago
Comment on attachment 356696 [details] [diff] [review]
Patch

Similar as the other bug.

Updated

9 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Pushed in changeset:
http://hg.mozilla.org/mozilla-central/rev/19e814487afb
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090202 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
Pushed to m-1.9.1 in changeset:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e171fe293271
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.