1639993 - Ensure the tab switch warning meets our accessibility standards.

Status: NEW

(Firefox :: Site Permissions, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

I'll reach out to the Accessibility team to see if there's someone over there who can help me ensure that we're not shipping something inaccessible.

Comment 1

[Asa Dotzler [:asa]]

I can help here with a review pass if you can provide instructions for enabling/testing the features.

Comment 2

[Asa Dotzler [:asa]]

Also, a good starting point for self review is https://wiki.mozilla.org/Accessibility/Requirements

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hi Asa,

Sure.

Briefly, the following changes are being worked on:

1. An updated WebRTC screen/mic/camera global indicator that works across all platforms (as opposed to the old one, which was only enabled on Windows and Linux).
2. A new checkbox in the screen sharing permission panel that allows users to silence DOM notifications while sharing their screen or window
3. A warning panel that is displayed when attempting to switch tabs when sharing that browser window or screen. This warning is displayed after the first tab switch, and allows users an opportunity to proceed with the switch. It also lets users allow all tab switches for the remainder of the screen/window sharing session. The idea here is to make it harder for users to accidentally share something on their screen that they didn't mean to (private stuff in background tabs, etc).

For now, this is probably best tested on either macOS or Windows (Linux support is still a bit flake-y, but I'm working on it).

Please set the following preferences:

privacy.webrtc.allowSilencingNotifications to true
privacy.webrtc.legacyGlobalIndicator to false
privacy.webrtc.sharedTabWarning to true

I've been using Talky.io as my test application, but the Zoom web app should work too, or https://permission.site/ if you want to go more fine-grained.

Here's an Invision spec that kinda highlights some of our design thinking here: https://mozilla.invisionapp.com/share/79X1W38HGAY#/screens

Comment 4

[Asa Dotzler [:asa]]

I've made a quick pass over the new UIs and for the most part things work. There are some exceptions. (I tested on Windows 10 with today's Nightly)

1. The switch tab warning pop-up only seems to appear for mouse tab switching and not for keyboard tab switching. This, if I'm testing it right, is the most serious issue I found as the new feature is completely unavailable to keyboard/screen reader users.

2. There are no focus rectangles on the sharing, mic and camera buttons in the sharing indicator window. The minimize button does have a focus indicator but not the other three buttons.

3. The "You are sharing [Window name]" in the sharing indicator window which is visually displayed isn't read by the screen reader, just the "stop sharing" button.

I'll continue testing but wanted to get you this feedback early.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Thanks, Asa.

Comment 6

[James Teh [:Jamie]]

I have some major concerns here:

1. A screen reader user isn't made aware of this indicator at all. We could probably use role="alert" on the window so users are notified when it appears.
2. Keyboard only users (including screen reader users) can't get to the window or its controls. Asa said he was able to alt+tab to it a few days ago, but that is no longer possible. Perhaps this is related to bug 1641495, which mentions the taskbar icon not being available when the indicator is minimised? For me, the taskbar icon is never available at all, hence no alt+tab.
   If we don't want alt+tab to get to it, my first thought is that ideally, f6 would focus it like it focuses all other notifications. Unfortunately, that's tricky (maybe impossible) because this is a global window. The problem is that if we use some other keyboard command, this isn't going to be discoverable.
3. Like the legacy indicator, this is triggering bug 1427304, which causes freezes/delays in screen readers. I need help from Windows widget folks to figure that out; there's a 1 year old NI without a response. :(
4. I'm not sure if this is part of the redesign or not, but the permission doorhanger for screen sharing includes a video with id webRTC-previewVideo which ends up in the tab order as an unlabelled grouping. I guess this is just focusable because videos are normally focusable? I don't think it serves any purpose, though, because as I understand it, you can't interact with that video in any way. Can we take this out of the tab order (tabindex="-1"?) or at least give it aria-label="Screen sharing preview" or something?

(In reply to Asa Dotzler [:asa] from comment #4)

3. The "You are sharing [Window name]" in the sharing indicator window which is visually displayed isn't read by the screen reader, just the "stop sharing" button.

That could be solved by giving div#display-share these attributes: role="group" aria-labelledby="window-share-info". Screen readers read group ancestors when a control gets focus.

Comment 7

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #6)

1. A screen reader user isn't made aware of this indicator at all. We could probably use role="alert" on the window so users are notified when it appears.

Ah. I see there's role="alert" on the html element. That's not going to work, nor does it work on the body element. I could probably tweak the a11y code to allow role="alert" on body for chrome documents... or you could wrap the entire content in another div/span with role="alert".

Comment 8

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #7)

Ah. I see there's role="alert" on the html element. That's not going to work, nor does it work on the body element. I could probably tweak the a11y code to allow role="alert" on body for chrome documents

Dealing with this in bug 1642258 and bug 1642260.

or you could wrap the entire content in another div/span with role="alert".

Actually, that wouldn't work because the alert event is only fired for the root of an inserted subtree. :(

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Re-purposing this bug to focus on accessibility issues for the tab switch warning only. I've attempted to open up bugs related to just the new global sharing indicator and notification silencing, and have them blocking bug 1643035 instead.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:mconley, could you consider increasing the severity?

For more information, please visit auto_nag documentation.

Comment 11

[Emma Zühlcke [:emz]]

Mike, is this something we should prioritize? Did we end up shipping the tab switch warning?

Comment 12

[Mike Conley (:mconley) (:⚙️)]

We did not ship it, and I wonder at this point whether we should just pull it out of the tree for now.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Unless somebody on Privacy / Security wants to push on improving it?

Comment 14

[Emma Zühlcke [:emz]]

Thanks, I'll bring this to the next team meeting, shipping this may fit in our backlog. Why did we not end up shipping it?

Comment 15

[Emma Zühlcke [:emz]]

Removing the access-s2 since this has not shipped.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

I don't remember - but looking through the bug list, I think we decided that (at the time) the potential for introducing tab-switch bugs was great enough to not wanting to turn it on by default.