Closed Bug 1052776 Opened 7 years ago Closed 5 years ago

Desktop notifications not accessible: Not read by screen reader, and fade away

Categories

(Toolkit :: Notifications and Alerts, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox42 --- fixed
firefox43 --- fixed
firefox44 --- fixed

People

(Reporter: MarcoZ, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file)

If desktop notifications are enabled from, for example, Gmail, or other websites that support them, and they appear, there are several accessibility problems:

1. Their appearance is not being picked up by a screen reader. Unlike the notifications in Thunderbird, for example, when new mail arrives.

2. It was reported to me by an accessibility software engineer at IBM that these notifications fade away after a timeout. This has accessibility implications for various groups of people with disabilities, not just screen reader users.
This is gaining some inquiries from friends now. Gijs, we need to put these on the radar for Firefox desktop.
Duplicate of this bug: 1184049
web notifications are being used in https://gitter.im/w3c/ and AT users are not getting the benefit of the notifications.
The web notifications API is implemented in Firefox
https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html

When web notifications are displayed there apears to be no announcement of the messages by assistive tech. 
demo page:
https://developer.cdn.mozilla.net/media/uploads/demos/e/l/elfoxero/c17223c414d8ddafb7808972b5617d9e/html5-notifications_1400214081_demo_package/index.html

Notes: 
the UI of the displayed web notification does have an accessibiity tree in Windows.

Tested with Firefox 39, NVDA and JAWS latest versions.
As I mention in comment #0, this has several problems:
1. It doesn't stay long enough for me to even grab at the tree of that notification. I can feel that it's there briefly with NVDA's mouse emulation, but only if I'm close enough to the spot in the bottom right corner of the screen where it appears.
2. No announcement, this is probably just a markup issue. That's why this is in toolkit.
3. No keyboard interaction. But this is generally the problem with these Windows bubbles.
4. They fade away after a few seconds. People with cognitive disabilities will have a hard time getting at these fast enough to act on them.
(In reply to Marco Zehe (:MarcoZ) from comment #5)
> As I mention in comment #0, this has several problems:
> 1. It doesn't stay long enough for me to even grab at the tree of that
> notification. I can feel that it's there briefly with NVDA's mouse
> emulation, but only if I'm close enough to the spot in the bottom right
> corner of the screen where it appears.
> 2. No announcement, this is probably just a markup issue. That's why this is
> in toolkit.

cc'ing Dao for ideas

> 3. No keyboard interaction. But this is generally the problem with these
> Windows bubbles.

it'd be nice to have interactive. For example, if the user focused it then it's not dismissed until the focus moves next. Also it'd be good to have dismission mechanism. Those hanging notifications may be annoying because they are overlapping with desktop/apps.

> 4. They fade away after a few seconds. People with cognitive disabilities
> will have a hard time getting at these fast enough to act on them.

should we have a pref to control timing?
Duplicate of this bug: 1207391
Push Notifications sprint team is working on changing the default fade away in bug 862395
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN
Attachment #8668057 - Flags: review?(MattN+bmo)
Comment on attachment 8668057 [details]
MozReview Request: Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN

https://reviewboard.mozilla.org/r/20881/#review18749

::: toolkit/components/alerts/resources/content/alert.js:72
(Diff revision 1)
> +
> +  let ev = new CustomEvent("AlertActive", {bubbles: true, cancelable: true});
> +  document.documentElement.dispatchEvent(ev);
>  }

I think this should be moved to `onAlertLoad` (probably near the bottom) as it's not just about prefilling and we may want to wait for some of the things at the beginning of `onAlertLoad` to happen.
Attachment #8668057 - Flags: review?(MattN+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/f3fd4b1a12ec
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Marco verified this.
Status: RESOLVED → VERIFIED
Comment on attachment 8668057 [details]
MozReview Request: Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN

Approval Request Comment
[Feature/regressing bug #]: web/firefox desktop notifications
[User impact if declined]: users of AT can't use web and app XUL notifications
[Describe test coverage new/current, TreeHerder]: there are tests for the notifications, but not for them being accessible (which would be a little tricky to do properly)
[Risks and why]: very low - basically, we fire some custom events and we fixed a mistake in how the accessible role of the notification windows was declared in the XUL markup. This shouldn't affect anything else.
[String/UUID change made/needed]: no.
Attachment #8668057 - Flags: approval-mozilla-beta?
Attachment #8668057 - Flags: approval-mozilla-aurora?
Blocks: 1210833
Comment on attachment 8668057 [details]
MozReview Request: Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN

OK, let's take it. Should be in 42 beta 4.
Attachment #8668057 - Flags: approval-mozilla-beta?
Attachment #8668057 - Flags: approval-mozilla-beta+
Attachment #8668057 - Flags: approval-mozilla-aurora?
Attachment #8668057 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.