If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[a11y] Firefox not firing an EVENT_HIDE for tooltips

RESOLVED INCOMPLETE

Status

()

Core
Disability Access APIs
RESOLVED INCOMPLETE
11 years ago
a year ago

People

(Reporter: Ginn Chen, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

Trunk
x86
All
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [auto-closed:inactivity])

(Reporter)

Description

11 years ago
 

Comment 1

11 years ago
Follow up from bug 366716.

Ginn, you sure this is a blocker? What's the use case for the EVENT_HIDE?

What events for show/hide on tooltips are going to be mapped to in ATK? Keep in mind that the tooltip accessible is always the same, and the EVENT_SHOW is a hack to make it work with MSAA, because it's what even it expects for them. However, as far as I know nobody cares when the tooltip actually goes away.
(Reporter)

Comment 2

11 years ago
Maybe it's not a blocker.

In ATK, I think show/hide mapped to state-changed:showing, state-changed:visible.
I'd like to make these events in pairs.
(Reporter)

Comment 3

11 years ago
I also noticed we're not firing EVENT_SHOW for progress bar, but we did fire EVENT_HIDE for it.
Is it a potential issue for at tools?
Hi guys, A possibly related question:
Does any AT currently expose the tooltip?  

nsXULTooltipAccessible::GetName seems to be just a stub.

Comment 5

11 years ago
ZoomText 9.1 beta does. And it's not a stub anymore:
http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULTextAccessible.cpp#90
(groan) Time for me to pull an update.  Sorry about that!

Comment 7

11 years ago
With respect to Ginn's question about progress meters:
It's a bit hacky, but we needed a way to make sure that screen readers knew when a progress meter started and stopped. We decided to use SHOW when it starts moving and HIDE when it goes away. Even if it's really an ancestor node that's being shown or hidden, the events will still always also happen directly on the progress meter, which makes it much easier to detect.

Here's where it's shown:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsRootAccessible.cpp#723

Here's where it's hidden:
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1124

If there's anything wrong with this we should file a separate bug.

Comment 8

11 years ago
Hmm, I guess we do need a separate bug since the nsRootAccessible part of the solution is ifdef'd for Windows-only.
(Reporter)

Comment 9

11 years ago
Bug 367369 filed for progress meter EVENT_SHOW issue

Updated

11 years ago
Blocks: 368875
No longer blocks: 342901

Updated

10 years ago
Duplicate of this bug: 398052

Comment 11

10 years ago
Ping. :-)

Right now, Orca can provide access to the tooltips that appear; while we don't announce anything (or have any desire to) when they disappear, we would like to be able to update the braille display to reflect what is showing (or not showing) on screen.  We cannot do that because of the lack of events: We think the tooltip is still visible.

Updated

10 years ago
Blocks: 374212

Updated

10 years ago
Whiteboard: orca:normal
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Yeah I can see not having an EVENT_HIDE on tooltips would be a major pain for braille. Joanmarie have you worked around this somehow or is it still a priority?

We should consider the trigger source for tooltips parents if possible.

Comment 14

8 years ago
We're not doing anything w.r.t. tooltips in Gecko because they're not keyboard accessible (in addition to this issue).
Jamie how does NVDA handle tooltips?

Comment 16

8 years ago
Err... it looks like NVDA doesn't handle Mozilla tooltips at all. We do handle native Windows tooltips, but we don't seem to handle the tooltip role generically for some reason. In any case, we only handle the show event because we just speak it. For such messages in braille, we normally pop up an alert which disappears after a configurable timeout. However, having it stay on the braille display until it disappears off screen makes a lot of sense, so yeah, the hide event would be useful for this purpose.

In other words, NVDA doesn't currently use it, but I think a hide event is a good idea.

Comment 17

8 years ago
(In reply to comment #14)
> We're not doing anything w.r.t. tooltips in Gecko because they're not keyboard
> accessible (in addition to this issue).

See bug #367364 for this issue.
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
Whiteboard: orca:normal → [auto-closed:inactivity]
You need to log in before you can comment on or make changes to this bug.