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

UNCONFIRMED
Unassigned

Status

()

Firefox
Disability Access
UNCONFIRMED
5 years ago
3 years ago

People

(Reporter: steve faulkner, Unassigned)

Tracking

(Blocks: 2 bugs)

15 Branch
x86
Windows Vista
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

5 years ago
Component: Untriaged → Disability Access
(Reporter)

Updated

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

Comment 1

5 years ago
Jamie, pro and con?

Updated

5 years ago
Blocks: 343213, 472809

Comment 2

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

Comment 3

5 years ago
Any difference between role="dialog" and role="alertdialog" from user perspective?

Comment 4

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

Comment 5

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

Comment 6

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

Comment 8

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

Comment 10

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

Comment 11

5 years ago
Wontfix? Steve, are you fine with that?

Comment 12

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

Comment 13

5 years ago
(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?

Comment 14

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

Comment 15

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

Comment 16

5 years ago
(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?

Comment 17

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

Comment 18

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.