Can you strip photo metadata using only a keyboard and a screen reader?

Why this isn't another "does the tool really work locally" page

This site already has a guide on how to tell if a browser tool really processes your photo locally, which is about verifying a privacy claim: does your file leave the device, yes or no. That's a question anyone can check with the network tab in their browser's developer tools, sighted or not. This page is about a separate layer entirely — once you trust that the processing happens locally, can you actually operate the page that does it without depending on vision or a pointer. A tool can be completely private and still be hard to use non-visually; those are independent properties, and conflating them is easy to do and worth avoiding.

What already works without a mouse or a screen

Read directly from this site's own markup and script, rather than assumed: the drop area that accepts a file is not a plain div with a click handler. It carries role="button", a tabindex="0", and an aria-label describing what it does, and its keydown handler explicitly listens for both Enter and Space and opens the file picker on either — the same two keys that activate a native <button>. The actual <input type="file"> behind it is hidden using the standard clip-rect technique (a 1px box, not display:none), which keeps it present and focusable in the accessibility tree instead of removing it outright — a detail that's easy to get wrong in a way that silently breaks screen reader access, and isn't wrong here. The page also doesn't suppress the browser's default focus outline anywhere in its stylesheet, so tabbing to the drop area shows a visible focus ring rather than an invisible one. Once a file is loaded, the remove-metadata, download and choose-another-image controls are ordinary <button> elements in document order, so Tab and Enter work on them exactly as they would anywhere else on the web. And when something goes wrong — wrong file type, a read failure — the error box is marked role="alert", which is an implicit live region, so a screen reader does interrupt and read that message immediately without the user having to go looking for it.

Where the interface goes quiet

The gap is on the success path, not the upload path. After the remove-metadata button is pressed, several things change on the page: the three-step progress indicator advances, a list of metadata findings fills in under a "Metadata check" heading, a before-and-after comparison panel appears with file names, types and sizes, a line stating whether obvious metadata markers remain in the cleaned copy, and the download button becomes visible. None of that is wrapped in an aria-live region, none of it carries role="status" or role="alert", and focus is not moved to any of it programmatically. For a sighted mouse user, all of this is visually obvious the instant it happens. For a screen reader user, pressing that button currently produces silence — the work has been done and the result is sitting in the page, but nothing tells you to go look for it. That's a real, verifiable gap in this specific page today, not a hypothetical one, and it's worth saying plainly rather than glossing over it.

A workaround that doesn't depend on the page fixing this

1. Press the remove-metadata button, then tab forward deliberately rather than waiting to hear something. The download button and comparison text are present in the page a moment after the button is pressed; they're just not announced at the moment they appear.
2. Use your screen reader's own "read from here" or continuous-reading command after a short pause, landing anywhere near the result area. Because the content is genuinely present in the DOM — just not pushed to you via a live region — a manual re-read of the page picks it up correctly.
3. Don't rely on this page alone for anything sensitive. Download the cleaned file, then open your operating system's own accessible properties view — Windows' Details tab in File Properties, or macOS's Get Info panel — both of which are built to work with a screen reader independently of any website, and independently check whether GPS and camera fields are actually gone.
4. If you use a browser extension or OS feature that announces page-title or live-region changes, it will not currently fire on this tool's result panel; don't treat its silence as a signal that something failed.

Common mistakes and misconceptions

"If a tool has ARIA roles on its buttons, it's fully accessible." Having correct roles, labels and keyboard handling on the controls — which this page does — only covers the input half of the interaction. A page can get every button right and still fail to tell an assistive-technology user that an action completed, which is exactly the split described above.

"No announcement means the removal didn't work." The processing itself — decoding the image to a canvas and re-encoding it — runs the same way regardless of whether the result is announced. The silence is a notification gap, not a sign that metadata wasn't actually stripped; the file download and result panel are genuinely there once you look.

"A visually hidden file input is the same as a broken one." Hiding an element with display:none removes it from the accessibility tree and from the tab order; hiding it with a clip-rect technique, which is what this page uses, keeps it focusable and announced while making it visually invisible. The two approaches look identical to a sighted user and are completely different to a screen reader.

"Keyboard accessibility and screen reader accessibility are the same thing." They overlap but aren't identical. This page's upload and control flow is fully keyboard-operable today. Its live-announcement behavior for a screen reader user is a separate, weaker story, even though both are usually lumped together as "accessibility."

Related guides

See also:

• How to tell if a browser tool really processes your photo locally
• Does stripping metadata remove an image's alt text?