1799211 - Save visible/Save full page buttons are not focused when opening Screenshots UI (component)

Status: VERIFIED FIXED

(Firefox :: Screenshots, defect, P2)

Description

[Tim Giles [:tgiles]]

STR

1. Set screenshots.browser.component.enabled to true
2. Navigate to https://bugzilla.mozilla.org/home (or any webpage)
3. Use keyboard shortcut (Ctrl + Shift + S on Windows, not sure on Mac or Linux) to take a screenshot
4. Press Tab key

Expected:

• Save Visible button receives focus

Actual:

• Focus stays on web content

Comment 1

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

In the extension, once the screenshots UI is shown, [TAB] places focus on the "Save full page" button. Tab again focuses "Save visible". There doesnt seem to be any way to focus the rest of the in-page UI (so no way to test if we can get back to it from there).

For the component implementation, shift+F6 focuses the popup with Save Visible. And tab again focuses Save full page. Again, it doesnt seem to be possible to reach the rest of the in-page UI to pick the region to capture, so there's no way to confirm we can get back to these buttons.

Comment 2

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

As noted in comment #1, the toolbar (which is implemented in a chrome popup) with the "save visible" / "save full page" buttons is accessible with Shift+F6. However, when you activate Screenshots (via ctrl+shift+s, or the context menu) there is no notification that this dialog now exists - should there be? And/or once focus is moved to this dialog, there's no spoken confirmation of this switch in context.

So this might be WORKSFORME, but I'd like to confirm expectations on how a user would even know about the toolbar dialog before closing this out. Can you advise Jamie?

Comment 3

[James Teh [:Jamie]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #2)

As noted in comment #1, the toolbar (which is implemented in a chrome popup) with the "save visible" / "save full page" buttons is accessible with Shift+F6. However, when you activate Screenshots (via ctrl+shift+s, or the context menu) there is no notification that this dialog now exists - should there be?

There definitely should be. I think the toolbar should get focus, ideally the first button, but the container would also be fine. In that case, the container should probably get role="dialog", since it's a pop-up. If it can't be focused for some reason, it needs to get role="alert" so that screen readers will at least report that it has appeared.

And/or once focus is moved to this dialog, there's no spoken confirmation of this switch in context.

I don't quite understand what you mean here. Do you mean there's no announcement that this is related to screenshots? That's a matter of setting the right roles (e.g. role="dialog") and label on the container.

So this might be WORKSFORME

Definitely not worksforme.

• With the extension, the initial focus is a bit weird; it lands on the extension document which gets a URL as its name. However, it's still very obvious that the screenshot UI has appeared and you can get to it easily. If there were a bug here, I'd rate it access-s4.
• In contrast, the component implementation provides no notification that the UI has appeared and getting to it isn't intuitive as it currently stands. The former in particular is an access-s2 and I believe it should block the implementation from shipping.

Comment 4

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

And/or once focus is moved to this dialog, there's no spoken confirmation of this switch in context.

I don't quite understand what you mean here. Do you mean there's no announcement that this is related to screenshots? That's a matter of setting the right roles (e.g. role="dialog") and label on the container.

Yes, that is what I mean. I'll try it both ways - leaving focus on the container or focusing the first button but mostly I wanted to confirm that I should expect an announcement of some kind.

the component implementation provides no notification that the UI has appeared and getting to it isn't intuitive as it currently stands. The former in particular is an access-s2 and I believe it should block the implementation from shipping.

Agreed. This bug currently blocks our meta bug for keyboard accessibility for the feature, but as some of those may be lower severity and end up not being blockers, I'll make this explicitly block bug 1789727. I'm also going to morph this bug a little as while you can technically focus those buttons today, its not in a usable state.

Comment 5

[BugBot [:suhaib / :marco]]

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 6

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

Yeah I can make this S2. Its probably somwhere between S3-S3 in reality as it is possible to place focus on the buttons, but the first button is not automatically focused - which we aim to fix here.

Comment 9

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

Attachment: Bug 1799211 - Place focus on the first panel button when opening screenshots UI. r?niklas!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18ac09635451
Place focus on the first panel button when opening screenshots UI. r=niklas

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/18ac09635451

Comment 12

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible with a 2022-11-04 Nightly build on Windows 10.
Verified as fixed on Firefox 112.0b2(build ID: 20230314181505) and Nightly 113.0a1(build ID: 20230314161405) on Windows 10, macOS 12, Ubuntu 22.
Tab can now focus the Save visible/Save full page options.