It should be possible to drive taking a screenshot entirely from the keyboard.

If this isn't a regression vs. the extension, and given the extension is still what we're shipping, should this really be S2?

(In reply to :Gijs (he/him) from comment #1)

If this isn't a regression vs. the extension, and given the extension is still what we're shipping, should this really be S2?

That's fair. For the component implementation this is high-severity, but for the feature as a whole, its a non-issue as we haven't shipped it yet.

We need to determine an access severity here. This seems like an access-s2, since the feature is completely inaccessible to some users. However, i don't really follow comment 1 and I'm mindful that autonag will complain if I set access-s2. Gijs, can you clarify the situation here?

Right now we ship screenshots as an extension. It's possible to take a full-page or viewport only screenshot with the extension using only the keyboard - Ctrl-Shift-S, then tab to either of the two buttons and hit space, then save the file or copy to clipboard using the buttons that appear at that point. I don't see any focus feedback on the X/copy/download buttons that appear at that point, and one of them should probably be auto-focused, but that's less severe than the description in comment 0. That's the thing we ship to users on release. This bug is not about the thing we ship to users. It may be worth filing a bug about the thing we ship to users, but AIUI we're trying to replace it with the "component" (rather than "extension") implementation, so it might not get fixed.

The implication from comment 0 is that the "component" implementation of screenshots (which I stress isn't used on release right now) cannot be driven entirely from the keyboard. Maybe Sam can offer more context on what he meant when he filed the bug. When I tried it just now, I can still use screenshots and the bug in the extension I mentioned (ie no visual focus indication on the last screen) has been fixed in the component implementation. You can try by toggling screenshots.browser.component.enabled to true in about:config. Specifically:

1. Ctrl-shift-S to bring up screenshots
2. use F6/Shift-F6 to cycle to the popup that appears (this should probably get focus automatically as part of fixing this bug - it only gets brought up in response to user action but doesn't appear to take focus)
3. tab to pick a button, space to activate
4. tab/space to pick between the buttons on the overlay
5. accept filepicker if necessary.

Neither the extension nor the browser component version have a way of doing an arbitrary-selection screenshot (ie something other than full page or viewport) or picking a specific element. This is driven entirely using mouse pointing. I don't know what a good accessible alternative for that would look like. To compare, I tried using devtools' inspect element using the keyboard just now (which has a similar-ish visual overlay experience for mouse users) but couldn't work out how to navigate the document with the keyboard - left/right arrow seem to allow moving to the top and bottom of the DOM tree, but up/down arrow or any other keys I could figure out do not allow moving across the tree (ie from one node to its sibling), so I think there we rely on the inspector's own DOM view to provide a keyboard-accessible alternative.

So honestly I'm not sure what needs to be done here but IMHO it doesn't seem like an access-S2. Worst case you could copy/save a full page screenshot and then crop appropriately in an image editing tool that does have keyboard support (though to be totally honest, I can't say I'm familiar with how you would do cropping in an image editing tool without a pointing device, either - reading Photoshop's manual there is no indication of how to do the equivalent of a simple rectangular drag selection with a keyboard).

We know we haven't spent much time on keyboard a11y in the new "component" implementation, so my intention with this bug was to identify and fix any such issues. And if there are none we can just close it as works-for-me. At minimum we need tests to assure this continues to be true however.

Driving the element and region/box picker from the keyboard should be possible, though we might want to file bugs for each so we can prioritize them separately, and make a decision on whether those need to be blockers. On windows you can resize a window with alt+space -> resize and use the arrow keys and we may be able to do something similar. Its a bit awkward as you have to toggle between move and resize but doable. Im also interested in ideas and best practices for this interaction - if there's software that handles this well I'd like to take a look and see what we can learn.

Also I should clarify that I expect this bug is a stepping stone to screenreader and AT support. We plan to identify and fix any obvious issues and gather up questions before approaching the a11y team for a deeper review and getting to more comprehensive accessibility for the feature. If the feature is already sufficiently testable I'm happy to start that process now, I just know we have a few issues we can take care of in the meantime.

Making this a meta bug, we don't expect patches on here; please file dependents for individual issues we can patch

We don't have keyboard accessibility for the extension so we don't think this should block landing on Nightly.
We still want to add keyboard accessibility so we are moving this to block 1696573

(In reply to Niklas Baumgardner [:niklas] from comment #8)

We don't have keyboard accessibility for the extension so we don't think this should block landing on Nightly.
We still want to add keyboard accessibility so we are moving this to block 1696573

That's not quite the right way to think about this. Firefox, and all of its features, should be accessible. If we're taking the time to re-implement, a11y should a hard requirement. We don't have to solve really difficult problems like how to do drag selection on content with the keyboard but basic keyboarding should be a requirement here.