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

Status: VERIFIED FIXED

(Toolkit Graveyard :: Notifications and Alerts, defect)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[Marco Zehe (:MarcoZ)]

This is gaining some inquiries from friends now. Gijs, we need to put these on the radar for Firefox desktop.

Comment 3

[steve faulkner]

web notifications are being used in https://gitter.im/w3c/ and AT users are not getting the benefit of the notifications.

Comment 4

[steve faulkner]

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.

Comment 5

[Marco Zehe (:MarcoZ)]

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.

Comment 6

[alexander :surkov (:asurkov)]

(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?

Comment 8

[Edwin Wong [:edwong]]

Push Notifications sprint team is working on changing the default fade away in bug 862395

Comment 9

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN

Bug 1052776 - fix role=alert usage and ensure alert events fire, r?MattN

Comment 10

[Matthew N. [:MattN]]

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.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f3fd4b1a12ec

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f3fd4b1a12ec

Comment 13

[:Gijs (he/him)]

Marco verified this.

Comment 14

[:Gijs (he/him)]

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.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e9537700904f

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/fb28b28ec9c7

Comment 18

[Firefox Bug Husbandry Bot]

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