Closed Bug 347247 Opened 14 years ago Closed 14 years ago

No way to dismiss a notification without a mouse

Categories

(Toolkit :: XUL Widgets, defect, major)

1.8 Branch
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: zeniko, Assigned: pilgrim)

References

Details

(Keywords: access)

Attachments

(2 files)

Either the close button should be in the tabbing order or the notification itself should be if there's no other tabbable widget inside (such as a button). Then hitting [Esc] should close that particular notification.

NB: This issue is particularly bad with the new blocking notification introduced in bug 343574.
Could just make the close button focusable.
Version: unspecified → 1.8 Branch
How is the notification presented to screen readers anyway? Don't we have to focus the whole notification when it appears so that it can actually be read to the user?

If so, we could just have notifications behave like alert dialogs: [Esc] and maybe also [Enter] and [Space] dismiss them whenever they're focused themselves, and only [Esc] when a sub-element is focused. The [Esc] part is also what we do for the Find bar, where the close button itself isn't focusable either.
How do I bring up one of these notification boxes?

Is it the same as the browsermessage that we use for popups etc.? Those fire an EVENT_ALERT to the screen reader. Also, the button has an accesskey mnemonic (see http://www.mozilla.org/access/keyboard/accesskey). When the screen reader gets the EVENT_ALERT, it reads the browsermessage along with the button and the mnemonic, so the user can hear how to deal with the alert.
Blocks: keya11y
Keywords: sec508
Yes, it fires an AlertActive event just like the old messages did. Note that now there may be more than one button. There may be more than one notification active at a time, but the event is sent when each is added.

The notification is currently displayed for blocked popups, missing plugins or when an extension cannot be installed.
Status: NEW → ASSIGNED
In bug 243752 we had a similar problem (how to close the sidebars), which we solved by putting the little close box in the tab order.  I suggest we do the same thing here.
Assignee: nobody → pilgrim
Severity: normal → major
Status: ASSIGNED → NEW
Attachment #234034 - Flags: first-review?(mconnor)
Flags: blocking-firefox2?
Comment on attachment 234034 [details] [diff] [review]
make close button tabbable

This gets my UI-R, fwiw, just like the sidebar. We can talk about adding ESC support for this as well, but that might lead to inconsistencies of their own.
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: --- → mozilla1.8.1
Mark, were you going to rev the patch so there's an accessible name?
Comment on attachment 234034 [details] [diff] [review]
make close button tabbable

Clearing review request for now.  Mark, please re-request if I misinterpreted the IRC discussion the other day
Attachment #234034 - Flags: first-review?(mconnor)
Attachment #234034 - Attachment is obsolete: true
Attachment #235429 - Flags: first-review?(mconnor)
Comment on attachment 235429 [details] [diff] [review]
make close button tabbable and give it a title

>+<!DOCTYPE bindings [
>+<!ENTITY % browserDTD SYSTEM "chrome://browser/locale/browser.dtd" >
>+%browserDTD;
>+]>

XUl widgets can't depend on a browser file as it won't exist in non-Firefox applications. You'll need to copy the text into a notification.dtd or something.
Comment on attachment 235429 [details] [diff] [review]
make close button tabbable and give it a title

hrm, we're string frozen too, so that makes Neil's solution wrong.

Maybe Esc while focused on any of the buttons, like a dialog?
Attachment #235429 - Flags: first-review?(mconnor) → first-review-
In that case, can we check in the original patch for FF2 and file a separate bug (targeted at FF3) about the lack of an accessible name?
Comment on attachment 234034 [details] [diff] [review]
make close button tabbable

(In reply to comment #13)
> In that case, can we check in the original patch for FF2 and file a separate
> bug (targeted at FF3) about the lack of an accessible name?

If that's ok for Fx2 from your perspective, then definitely!
Attachment #234034 - Attachment is obsolete: false
Attachment #234034 - Flags: first-review+
Comment on attachment 234034 [details] [diff] [review]
make close button tabbable

Can we get this landed on the trunk and then nominated for RC1? Danke!
Whiteboard: [checkin needed]
I had misunderstood what notification we were talking about. This isn't an important enough sec508 bug to block the release in my opinion. Making close buttons focusable is not at all normal.

You can in fact remove the notifications if you choose one of the options from the Options button. So I'm not convinced this is a realy sec508 bug.

Another thing is that Mark is on vacation until Monday and time is getting short. I see no critical need for this.
Flags: blocking-firefox2+ → blocking-firefox2?
Unblocking as per Aaron's comments ...
Flags: blocking-firefox2? → blocking-firefox2-
mozilla/toolkit/content/widgets/notification.xml 	1.9
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: mozilla1.8.1 → mozilla1.9alpha1
You need to log in before you can comment on or make changes to this bug.