Open Bug 788428 Opened 12 years ago Updated 2 years ago

ARIA alertdialog role does not fire system alert event when its visibility changes from hidden to visible

Categories

(Firefox :: Disability Access, defect)

Product:
Firefox
Component:
Disability Access
Version:
15 Branch
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: faulkner.steve, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

opened http://www.html5accessibility.com/tests/dialogrole.html pressed the opne button which displays (changes display:none to display:block) a div with role=alertdialog


Actual results:

the div appears but no alert event is fired


Expected results:

the div appears and an alert event is fired
Component: Untriaged → Disability Access
Summary: ARIA alertdialog role does not fire system alert event when its visibility chnages from hidden to visible → ARIA alertdialog role does not fire system alert event when its visibility changes from hidden to visible
Jamie, pro and con?
Imo, an alertdialog doesn't need to fire the alert event anyway because it gets focus. Only an alert needs to fire the alert event because it doesn't get focus, so the AT needs to know to trigger alert behaviour.

Having said this, NVDA already has code to filter out the alert event for something that has the focus (to avoid double reporting), so I don't think doing this will break us.
Any difference between role="dialog" and role="alertdialog" from user perspective?
Not exactly from the user perspective. However, the spec seems to suggest that the AT should calculate the description itself for alertdialog if no aria-describedby is provided, but should never do this for dialog. (This creates ugliness because a11y APIs don't really differentiate between these roles except for ARIA specific properties; e.g. xml-roles in IA2.) See this NVDA ticket for a rather lengthy discussion about this:
http://www.nvda-project.org/ticket/2390
(In reply to James Teh [:Jamie] from comment #4)
> Not exactly from the user perspective. However, the spec seems to suggest
> that the AT should calculate the description itself for alertdialog if no
> aria-describedby is provided, but should never do this for dialog. (This
> creates ugliness because a11y APIs don't really differentiate between these
> roles except for ARIA specific properties; e.g. xml-roles in IA2.) See this
> NVDA ticket for a rather lengthy discussion about this:
> http://www.nvda-project.org/ticket/2390

the browser could calculate the description for alertdialogs if it's omitted if it helps. But I'm not sure I understand the difference between these roles at all.

Also I don't really understand why we need to fire alert event if AT don't need it. Steve, do you know why the spec requires that?
The ARIA implementation guide [http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table] has a SHOULD requirement on firing an alert event for the alertdialog role. IE fires an alert event.
The alertDialog role is approprate to use in cases where developers are emulating a JavaScript alert().
FWIW, all screen readers I know on any platform read dialog text automatically when it appears. This includes the dialog brought up by the JS alert() function. In all browsers I know, this is a standard dialog, except for Firefox, where we emulate it, since the dialog is tab specific. IMO, we should not do anything specific for alert dialogs that we don't do for dialogs in general anyway. On the contrary, the firing of the alert event might conflict with the general mechanism to speak dialogs, and even introduce user-unfriendly double speaking.
(In reply to Marco Zehe (:MarcoZ) from comment #7)
> FWIW, all screen readers I know on any platform read dialog text
> automatically when it appears. This includes the dialog brought up by the JS
> alert() function. In all browsers I know, this is a standard dialog, except
> for Firefox, where we emulate it, since the dialog is tab specific. IMO, we
> should not do anything specific for alert dialogs that we don't do for
> dialogs in general anyway. On the contrary, the firing of the alert event
> might conflict with the general mechanism to speak dialogs, and even
> introduce user-unfriendly double speaking.

hi Marco,

I think then that alertdialog should be dropped from ARIA as it appears to offer nothing and causes interop issues as it does fire an alert event in IE at least.
Steve, I never found anyone who was able to explain to me the difference between dialog and alertdialog in ARIA. Even Aaron couldn't. :) So I agree with your assessment that maybe it's time to drop alertdialog from the spec. Alerts, as I came to know them, are what Jamie said: Compound controls that inform the user, but don't grab focus, optionally allowing interactions via keyboard shortcuts or tabbing to them. Dialogs are modal things that grab focus, and historically, screen readers all make a point to deliver the important message a dialog has to communicate, immediately.
As I said in comment 4, some believe the difference relates to automatic calculation of description. The spec says the AT will calculate dialog text for alertdialog, but it doesn't say this for dialog. The problem is that without this differentiation, there is no elegant way for an author to create a dialog with *no* caption, which is a valid use case, since automatic dialog text calculation can be inaccurate. (The only way is to create an empty div and reference that with aria-describedby, but that is *really* ugly.) We've now implemented it like this in NVDA because an author specifically requested this. See the NVDA ticket I referenced earlier for more info.
Wontfix? Steve, are you fine with that?
That depends. Technically, if an alert event is fired for alertdialogs when they are inserted (I can't remember), it should also be fired when they are shown for consistency. In other words, either drop the alert event for these altogether or fix this bug. Either way, it should be consistent.

Btw, the talk of dropping alertdialog seems to have completely missed my comment 10. I also stated this in comment 4.
(In reply to James Teh [:Jamie] from comment #12)
> That depends. Technically, if an alert event is fired for alertdialogs when
> they are inserted (I can't remember), it should also be fired when they are
> shown for consistency. In other words, either drop the alert event for these
> altogether or fix this bug. Either way, it should be consistent.

Firefox doesn't fire alert event for alertdialog at all and it seems we concluded that events aren't needed.

> Btw, the talk of dropping alertdialog seems to have completely missed my
> comment 10. I also stated this in comment 4.

It seems so. Did you comment the thread about alertdialogs dropping? Should browser calculate the missed description in case of alertdialogs?
(In reply to alexander :surkov from comment #13)
> Firefox doesn't fire alert event for alertdialog at all and it seems we
> concluded that events aren't needed.
In that case, wontfix.

> Did you comment the thread about alertdialogs dropping?
I replied noting that I'd commented on this bug explaining why it should be kept.

> Should
> browser calculate the missed description in case of alertdialogs?
That'd be fantastic. That said, screen readers have been calculating dialog descriptions themselves for years, so it isn't a "bug" that Firefox doesn't do this. The real ugliness is that we have to use xml-roles to determine whether to do it or not.

Perhaps we need a "explicit-description:true" object attribute. This would be exposed if a) @aria-describedby is set, or b) @role="dialog" even if @aria-describedby is not set. In the latter case, this indicates that the author explicitly did not want a description. This sounds a bit weird, though. Perhaps we can come up with something better.
Wouldn't it be work if
1) if aria-describedby is used on @role="dialog", @role="alertdialog" then IAccessible::get_description is exposed and automatically announced by AT
2) if no aria-describedby is specified for @role="alertdialog" then Firefox repairs the description and exposes it as IAccessible::get_description which is announced by AT
(In reply to alexander :surkov from comment #15)
> 1) if aria-describedby is used on @role="dialog", @role="alertdialog" then
> IAccessible::get_description is exposed and automatically announced by AT
We already do this.

> 2) if no aria-describedby is specified for @role="alertdialog" then Firefox
> repairs the description and exposes it as IAccessible::get_description which
> is announced by AT
This would already work too.

However, there is a third case:
3) If no aria-describedby is specified for @role="dialog", then IAccessible::accDescription is empty.
The problem is that we can't tell the difference between empty (meaning the author explicitly chose no description) and empty because the author didn't care and thus it is expected that the AT will calculate. This is true for all IAccessible implementations. We could make an exception for future versions of Mozilla (arguing that Mozilla do it properly :)), but the reality is that calculation of descriptions has become the rule, rather than the exception. In other words, without some sort of explicit communication, Mozilla would be the exception, even if we believe it's the right thing to do. The joys of legacy, huh?
(In reply to James Teh [:Jamie] from comment #16)

> However, there is a third case:
> 3) If no aria-describedby is specified for @role="dialog", then
> IAccessible::accDescription is empty.
> The problem is that we can't tell the difference between empty (meaning the
> author explicitly chose no description) and empty because the author didn't
> care and thus it is expected that the AT will calculate. 

then I'm not sure what the difference between role="dialog" and role="alertdialog" if for both of them you need to calculate a description.
we have different implementations across 3 browsers:
Firefox: no alert
IE: alert state
Chrome: aria-live=assertive

which results in different behaviours, I don't mind what is decided, but would be helpful to converge on one behaviour so we don't get quirks that devs have to work around.

Hmm, just came across this issue now. I noticed that NVDA speaks an alertdialog that gets focus inside of it in Firefox, but not in Chrome. Not sure what we're doing differently yet. Chrome also doesn't currently fire the alert event, meaning that both browsers contradict the ARIA spec for alertdialog.

We should definitely try to clear this up and harmonize everything.

JAWS currently needs the alert event or won't read the alert dialog's text.

Perhaps this means the alert event should be fired in order for JAWS to work? Jamie, as you said, it won't do any harm since NVDA will filter it out anyway when something inside the alertdialog gains focus.

Checked with JAWS and they agree there is no need to fire the alert event for an alertdialog, since focus is going inside the alertdialog. We think the ARIA spec should be changed instead.

JAWS is going to put in a fix on their end.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.