1820015 - Keyboard navigation between Screenshot's panel, overlay and content document is not possible (component)

Status: VERIFIED FIXED

(Firefox :: Screenshots, defect, P1)

Description

[Sam Foster [:sfoster] (he/him)]

With screenshots.browser.component.enabled set to true:
We need to enable keyboard navigation between:

• the popup panel (with "capture visible" | "full page" and "copy" | "download" buttons)
• the overlay UI (with the region drag handles, element picker and associated "copy" | "download" buttons)
• the content document - to allow the user to scroll/navigate within the document to get the correct stuff in the viewport

I'm leaving P1 - as this is our next priority for Screenshots, but S3 as this WIP version is still behind a pref and the default extension implementation does currently allow you to tab from the Screenshot buttons toolbar back out to the location bar and through to the content document. I'm not able to get to the any of the rest of the overlay content however.

Comment 1

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

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

For more information, please visit auto_nag documentation.

Comment 2

[Sam Foster [:sfoster] (he/him)]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #1)

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

I don't think we need to - see comment #0. This is behind a pref and already blocks enabling the feature. The workaround is to not enable the pref and get the slightly-better keyboard a11y of the existing extension implementation.

Comment 3

[Sam Foster [:sfoster] (he/him)]

I'm getting nagged about this being a P1 but appearing inactive. I've started looking into this and I think :niklas has too. I'll assign to myself for now. I think we're most likely looking at 114 for this - but its early days and I don't really know enough about the solution to make any kind of accurate prediction.

Comment 4

[Sam Foster [:sfoster] (he/him)]

Some context for the problem:

• When you activate Screenshots, we show a <panel> with the "Save visible" | "Save full page" buttons, and the first button receives focus. This panel serves a couple of functions: by overlapping the browser chrome we indicate this is a trustable browser feature, not just spoofing shenanigans the content is doing. And these 2 options are the most frequently used, so you can start and finish the whole operation with just a couple of keystrokes or mouse clicks.
• The rest of the Screenshot functions are available through an overlay we position on top of the content document. This lets you constrain the capture rectangle to a particular element or coordinates. Initially we just show a "cancel" button here. Once a region is identified, we show cancel | download | copy buttons in the overlay.
• We don't want to prevent the user from focusing the content document and scrolling or tabbing through it. Thats particularly important for a keyboard user as it lets them navigate to the part of the document they are are interested in into the viewport, so "capture visible" produces the screenshot they need.

So, to the problems.

• If you tab through the focusable elements in the <panel> , it just loops around; you need to F6 to move focus to the content document. That has its own discoverability problems. We can work around this by listening for keydown events and manually moving focus on tab. But once focus moves out of the panel, the user needs to know to F6 to get back in there.
• Its not currently possible to get at the overlay UI from the keyboard. F6 skips over the overlay and moves focus directly to the content document.
• If we did manually place focus in the overlay, you'd tab through the focusable elements, then on to the content document, and then back to the browser toolbars and you can't get back to where you started in the screenshots panel without F6.

Some thoughts on solutions and next steps:

• Ideally we'd insert the overlay into the document(?) collection that the focus manager cycles through. I suspect because we need to use the anonymous document / canvasFrame for that, it is explicitly excluded from that collection.
• F6 is kind of a power user move. Its well known in some groups of users, and completely unknown in others. I personally think that it should always be a shortcut to speed up an operation that you could otherwise accomplish with TAB. But I don't want to boil the ocean with this bug so I'm just looking for a intuitive keyboard experience to get at the functions Screenshots provides
• Driving the region and element selection features from the keyboard is a bit of a stretch goal (bug 1801954, bug 1801957) but seems like something we should eventually enable. So while there isn't much value today in the overlay UI for a keyboard user, we can't just kick this can down the road. But maybe we don't need to block bug 1789727 on a full solution to this problem.

Comment 5

[Sam Foster [:sfoster] (he/him)]

Bug 1824886 provides a shadowRoot we can reach for the anonymous overlay content, and crucially gives us a way to get an element reference we can pass into the focus manager's set/move focus methods.

Comment 6

[Sam Foster [:sfoster] (he/him)]

Attachment: WIP: Bug 1820015 - WIP: Make the screenshots overlay UI keyboard accessible

Comment 7

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1820015 - Make the screenshots UI keyboard accessible. r?niklas!

• Move the chrome panel buttons into a box which is inserted into #navigator-toolbox
• Adjust what open/closed means using hidden instead

TODO:

• Find a sensible way to restore previous focus (see <panel>) when screenshots is dismissed
• Review new keyboard UX
• Add a transition when opening the "panel" (could be follow-up)
• Maybe rename things that refer to "panel" to avoid confusion

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f28defeeb4ec
Make the screenshots UI keyboard accessible. r=niklas

Comment 9

[Atila Butkovits]

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

Comment 10

[Negritas Sergiu, Desktop QA]

Hello! I can confirm that the issue is fixed with 123.0a1 (2023-12-21) on Ubuntu 22.04, MacOS 12.6 and Windows 11. I will update the flags accordingly.