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

VERIFIED FIXED in Firefox 42

Status

()

defect
VERIFIED FIXED
5 years ago
20 days ago

People

(Reporter: MarcoZ, Assigned: Gijs)

Tracking

(Blocks 1 bug, {access})

Trunk
mozilla44
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed, firefox43 fixed, firefox44 fixed)

Details

Attachments

(1 attachment)

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.

Comment 3

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

Comment 4

4 years ago
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?
Push Notifications sprint team is working on changing the default fade away in bug 862395
Assignee

Updated

4 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Assignee

Comment 9

4 years ago
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
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Assignee

Comment 13

4 years ago
Marco verified this.
Status: RESOLVED → VERIFIED
Assignee

Comment 14

4 years ago
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?
Assignee

Updated

4 years ago
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.