Can You Redact a Screenshot Using Only a Keyboard?

One sentence carries this page: every control on this page is keyboard-reachable except the single action the whole tool is built around, drawing a selection over the thing you want hidden.

Two different accessibility questions

"Accessible" usually gets asked about the finished file: will a screen-reader user, a magnifier user, or someone with low vision be able to make sense of a redacted image once it's been shared? That's a real question and a separate page on this site works through it in detail, covering text alternatives, contrast on the redaction mark itself, and what happens to a black box under heavy magnification. It is a question about the output, asked after the editing is already done.

This page asks something upstream of that: can the person doing the redacting operate the editor at all if a mouse, trackpad, or touchscreen isn't available to them, whether that's a permanent motor impairment, a switch-access or head-pointer setup, a temporary injury, a broken trackpad on a borrowed laptop, or simply someone who navigates everything by keyboard out of habit. A tool can be perfectly screen-reader-friendly as an output and still be impossible to use as an input device, and the two problems need separate answers because they live in completely different parts of the code.

What already works with just Tab and Enter

Checked directly against this page's own markup rather than assumed: Choose Image, Black Box, Blur, Pixelate, Rectangle, Oval, Lasso, Undo, Clear, and Download PNG are all real <button> elements. That matters more than it sounds like it should, because native buttons get keyboard focus order and Enter- or Space-key activation from the browser automatically, with zero extra code written for it. Tab from the top of the page and every one of those ten controls is reachable and pressable in sequence, in the exact order they appear. Pasting an image with Ctrl+V also works without touching a pointer at all, since the paste handler listens on the whole document, not on anything that has to be clicked first.

So a keyboard-only visitor can open this page, paste or choose an image, switch between Black Box, Blur, and Pixelate, switch between Rectangle, Oval, and Lasso, and, once something has been redacted, undo it, clear it, or download the result. Every step up to and after the actual redaction is covered.

The one action with no keyboard path at all

What sits in the middle of that sequence, placing the box, oval, or lasso trace over the region to be hidden, is implemented entirely through pointer events: mousedown, mousemove, and mouseup for a mouse or trackpad, and touchstart, touchmove, and touchend for a touchscreen. A full read of the inline editor script turns up zero keydown, keyup, or keypress listeners anywhere in it, and the canvas element carries no tabindex, so it cannot even receive keyboard focus on its own. There is no arrow-key nudge, no "press Enter to drop a corner," no coordinate-entry field, nothing. A visitor who can reach every button on the page by keyboard still cannot mark a single region on the image, because that one gesture, start a drag, move, release, has no keyboard equivalent built into this editor today.

This is worth separating from a vaguer complaint like "canvas tools are generally bad for accessibility." The specific, checkable fact here is narrower and more useful: the buttons are fine, the drawing gesture is the entire gap, and it's the same gap whether you're trying to draw a rectangle, an oval, or a freehand lasso.

What the keyboard accessibility standard actually says about this

The relevant rule is Web Content Accessibility Guidelines Success Criterion 2.1.1, titled Keyboard, which sits at the most basic conformance level, Level A. In plain terms its goal is that everything on a page can be done with a keyboard except freehand movements, and its official wording carries a specific carve-out: it does not apply "where the underlying function requires input that depends on the path of the user's movement and not just the endpoints." That exception exists precisely for things like freehand drawing, where the shape traced, not just a start and end point, is the point of the gesture.

Applying that distinction honestly to this editor's three shapes gives a nuanced answer rather than a uniform one. A lasso trace genuinely depends on the path, so it fits the exception cleanly; there's no obvious way to keyboard-ify "trace this exact outline" without changing what the lasso tool is. A rectangle or an oval, by contrast, is fully defined by two endpoints, a starting corner and an ending corner, not by the path taken between them. By the standard's own logic, that means a rectangle or oval selection does not inherently require freehand input, even though none of the three shapes currently has a keyboard equivalent in this editor's code. None of this is a legal judgment about whether this or any other specific site is obligated to meet WCAG, since that depends on who is publishing it and under what law; it's only a description of how the standard itself is normally interpreted.

Workarounds that live outside this editor

If a keyboard path doesn't exist inside the tool, the remaining options sit at the operating system level, and they work because a browser generally cannot tell a real mouse movement from an emulated one. Windows and macOS both ship an accessibility feature usually called Mouse Keys, which lets the numeric keypad move the pointer and perform a press-move-release sequence that looks, to any webpage, exactly like a mouse drag. Switch-access scanning software and some head-pointer or eye-tracking systems work on a similar principle, driving the system pointer rather than talking to any one website directly. Because this editor's drawing code only cares about pointer position and pointer up or down, not about what produced those events, a correctly configured OS-level tool should be able to drive the Rectangle, Oval, or Lasso tool the same way a mouse would.

That comes with real caveats, so treat it as a starting point to check on your own system rather than a guarantee. Exact feature names, default key combinations, and how well click-and-drag is supported vary by operating system and by version, and some assistive setups emulate movement far more smoothly than drag gestures specifically. If you rely on one of these tools, it's worth testing the drag step on a low-stakes image before trusting it on something sensitive.

Common mistakes and misconceptions

"The buttons are keyboard-accessible, so the tool is keyboard-accessible." Reaching every button by Tab and Enter is real and confirmed from the code, but none of those buttons substitute for the one step they all depend on: having already marked a region to apply them to. A tool can pass that check entirely and still be unusable end to end for someone who has no pointer device.

"This is the same issue as the screen-reader accessibility of the final image." It isn't. One is about whether a published, already-redacted file can be understood by someone using assistive technology to perceive it. This is about whether the person doing the redacting can operate the editor at all, regardless of whether they can see the screen perfectly well. A sighted person who simply cannot use a mouse hits this exact same wall.

"Switching to a touchscreen instead of a mouse solves it." It doesn't, because a touchscreen drag is still a pointer gesture, just on a different surface, and this editor's touch handlers require the same start, move, release sequence as the mouse handlers do. Someone who cannot perform that motion with a mouse generally cannot perform it on a touchscreen either.

"Switching from Lasso to Rectangle fixes the keyboard problem." Not currently. All three shapes, Rectangle, Oval, and Lasso, are driven by the same pointer events with no keyboard listener attached to any of them. Rectangle and Oval are the two shapes where a keyboard equivalent would be technically straightforward to add, defined by two endpoints rather than a path, but as the code stands today, none of the three has one.