286240 - No ATK event for alerts

Status: RESOLVED WONTFIX

(Firefox :: Disability Access, defect)

Description

[Aaron Leventhal]

Spun off from bug 285711

Firefox has a concept of alert bars that popup but don't have a unique window.
For example, security alerts or an annoucement of a plugin that needs to be
installed.
For an example, go to http://ted.mielczarek.org/code/mozilla/extensiondev/ and
click on install. It won't actually install anything until you confirm. The
alert bar is at the top of the content.

For MSAA we firing EVENT_ALERT on the object when it pops up. This will allow an
AT like a screen reader to announce the alert and allow the user to take action. 
What even should we do for these situations in ATK?

The message itself is currently implemented as ROLE_ALERT in both MSAA and ATK.

Comment 1

[Aaron Leventhal]

I'm a little nervous about the idea of faking ATK to make it appear that some
objects are top level windows which really aren't. What if the AT wants to
assume that those really do match top level windows? The AT might have logic
where it compares the accessibility hierarchy with the window hierarchy.

Maybe it would be good to remove the requirement for certain objects like menus
and alerts to be top level windows. That assumption is flawed, especially with
DHTML accessibility. A web page will be able to provide an alert or a menu. I
think we should solve these problems by adding the required events to ATK.

Comment 2

[Bill Haneman]

I don't consider the proposal to be fakery.  Toplevel windows are an ATK
concept, which need not map to any specifics of the underlying implementing toolkit.

From the user perspective, popups are windows.  Thus it is with ATK and AT-SPI.

Comment 3

[Bill Haneman]

ATK already has the events necessary in my opinion.  But the core issue here is
that the popup should be a toplevel window anyway, as are other popups in other
toolkits.  The AT will not look at the "window hierarchy" as seen by the
underlying toolkit, as this has no defined mapping to atk or at-spi.

Comment 4

[Aaron Leventhal]

(In reply to comment #3)
I'm sort of okay with the "top level window" relating only to user perception,
however the Mozilla alerts don't pop up like that.

The example URL I provided in the bug description shows that the alert isn't a
perceived window. It's a message bar across the top, perhaps conceptually it is
a pane of the browser content window. I would like to better understand the
definition of a window and top level window under ATK.

What ATK event should be fired when the alert becomes visible? Does it all hinge
on the alert being in a conceptual window?

Comment 5

[Bill Haneman]

Generally, if an alert has already existed, but wasn't visible, then you get an
object:state-changed event whose details let you know that the VISIBLE state has
gone from FALSE to TRUE.  On the other hand, if the object is newly created, you
get an object:children-changed:add event.

At the moment I doubt that the AT is paying much attention to the appearance and
disappearance of unfocussed objects (there are too many of them to present them
all to the user).  But, the AT _does_ always listen to changes in
toplevel-window creation, activation/deactivation, etc. because that almost
always means changes in the user's context or operating environment.  On the
whole, it's troublesome to present information from unfocussed objects - at the
same time, you don't want to have focus jumping all over the place _except_ when
new dialogs are posted (this seems to be one of the few situations where
usability folks accept 'focus stealing').

What might be a useful approach for the AT, then, is to present information for
newly-created (or newly-visible) objects of ROLE_ALERT.  It makes conceptual
sense, because it means that an 'ALERT' object has recently been presented to
the end-user; a sighted user may choose to ignore, but certainly an unsolited
attempt to get the user's attention has taken place.

If the AT takes such an approach (particularly, alternate-modality AT such as
screenreaders or even magnifiers), then the creation of, or "exposure of" an
AtkObject of ROLE_ALERT may be a sufficient hint that the object in question
should be explicitly presented to the user, even if it does not explicitly gain
focus or cause a new window to pop up.

I'm at a bit of a disadvantage because I don't have Firefox on my own system. 
But if the object "looks like a popup" in the traditional "popup menu" or dialog
sense, I think it should be exposed conceptually as a toplevel.  If, on the
other hand, it's more of an urgent "status gadget" which doesn't pop over or
obscure the rest of the UI, I think the 'creation of ALERT object child of
current application' heuristic may be the right choice.

THoughts?

Comment 6

[Aaron Leventhal]

This has been rejected, other events will be used.

Comment 7

[Firefox Bug Husbandry Bot]

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