Using this converter with a keyboard and no mouse

The Tab order, measured

Fresh page load, then Tab pressed once at a time, recording what had focus after each press. The converter sits above the guide list, so if the upload area were reachable it would have to appear early:

Tab	What has focus	Where it goes
1	Brand logo	/
2	Guides	/guides
3	About	/about
4	Privacy	/privacy
5	Contact	/contact
6	Quality menu (<select>)	—
7	First guide link	/heic-to-jpg-without-javascript
8–11	Four more guide links	guide pages
12	"More guides"	/guides
13–18	Footer brand and five footer links	/, /guides, /about, /privacy, /contact

Eighteen stops, and the drop zone is not among them. Shift+Tab works as expected for going backwards — from the eighth stop it returned to the seventh — so this is not a focus trap; the upload area is simply not in the chain.

Why the keyboard cannot reach it

Three measured facts about that element:

• It is a <div>, not a <button>. Its tabindex property is -1, and it carries no tabindex attribute, no role attribute and no aria-* attributes at all.
• Calling focus() on it does nothing — focus stays on <body>. A keyboard has no way to put focus there.
• The file input inside it is <input type="file" hidden> with a computed display: none. It is not rendered, so it is not a tab stop either.

The element still looks fully alive to the eye: computed display: flex, cursor: pointer, and a box 714 × 180 pixels sitting 288 px from the top of the page. Nothing about it is dimmed or marked unavailable. That gap between how it looks and what the keyboard can do is the whole problem.

Pressing Enter on every stop

Maybe the picker is reachable some other way — perhaps a key handler on the page, or on the quality menu. So I reloaded the page and, for each of the first fourteen tab stops, pressed Enter on whatever had focus. I watched for the browser's own file-chooser event, which is the same event a real file dialog produces:

• 0 of the 14 stops opened a file picker.
• 10 of them were links, so Enter did what links do: it navigated to another page.
• 4 did nothing at all — the brand logo at stop 1 and the footer links at stops 13 and 14 (they point at the page you are already on), and the quality menu at stop 6.

I also tried the two keys that normally stand in for a click on a control that has focus: Enter and Space, with focus on the upload area, on the body, and on the quality menu. None of the three produced a file picker, and the console stayed empty.

To be sure the test was not simply blind, I clicked the drop zone with a real mouse event: the file chooser event fired immediately, once. So the click handler is there and works. Only the keyboard route is missing.

What does work without a mouse: the quality menu

The quality menu is a native <select> with a proper <label>, and every standard key worked. Starting from the default 85%:

Key	Value after	Option
(initial)	0.85	Good — 85%
ArrowDown	0.75	Smaller file — 75%
ArrowDown again	0.75	Smaller file — 75% (already last)
ArrowUp	0.85	Good — 85%
Home	0.95	High — 95%
End	0.75	Smaller file — 75%
Letter G	0.85	Good — 85%

Choosing a value with the keyboard is not cosmetic — it changes the output. Converting the same 700×476 photo after reaching a setting by keyboard only:

Reached by	Setting	Output	Page showed	Time
ArrowDown	0.75	30,231 bytes	sample.jpg — 700×476 — 30 KB	846 ms
Home	0.95	57,617 bytes	sample.jpg — 700×476 — 56 KB	611 ms
End	0.75	30,231 bytes	sample.jpg — 700×476 — 30 KB	705 ms

Those are the same byte counts this converter produces for that photo at those settings with a mouse — see the repeat-conversion measurements. Whatever route you take to the setting, the encoder behaves identically.

Once a file is in, the rest is keyboard-friendly

This is the part worth knowing if you use a keyboard for everything else. I supplied the file at the browser level — the equivalent of the file dialog returning — and then used only Tab and Enter from there:

• Conversion finished in 710 ms and the page showed sample.jpg — 700×476 — 37 KB. Focus afterwards was on <body>: the page does not move focus to the result, so you have to Tab to find it.
• The download link is 7 Tab presses from the top of the page. Pressing Enter there downloaded a real file — the browser reported a download of 38,078 bytes named sample.jpg, and the file landed on disk. The page stayed put; it did not navigate away.
• "Convert another" is the 8th stop, one Tab further. Enter on it hides the result block. One wrinkle: the hidden block keeps its old text and its old download address — the info line still read sample.jpg — 700×476 — 37 KB and the link still pointed at the previous file's blob URL, even though nothing was visible any more.

Focus rings, and what a screen reader is told

I sampled the first 12 tab stops and read their computed focus ring while they had focus. All 12 showed the browser's default ring — outline: auto, 1 px, rgb(16, 16, 16) — and all 12 matched :focus-visible. So this is not a page where focus has been deliberately suppressed: wherever the keyboard can go, you can see it.

The accessibility tree tells the same story from the other side:

Element	Role	Accessible name	Focusable
Upload area	generic	(empty)	no
Quality menu	combobox	"Quality"	yes
Download link	link	"Download JPG"	yes
Convert another	button	"Convert another"	yes
The hidden file input	not present in the tree at all

The upload area is exposed as a generic container with an empty name — there is nothing there that reads as a control, because there is nothing there that behaves as one. The two controls that do work have proper names. Counting across the whole page: 2 aria-* attributes (both aria-hidden on decorative icons), 0 role attributes, 0 aria-live regions, 1 <label>, 0 skip links, and 0 tabindex attributes. I did not run a real screen reader, so I have no result for how any specific one announces this page.

Everything else on the site behaves differently in a good way. On the guides index I counted 30 tab stops and every single one was a link — ordinary prose pages are fully keyboard-navigable, which is why the converter stands out.

What would fix it

I tried four fixes, in my own browser only — this is client-side surgery on a copy of the page in my own Chrome, nothing on the site was changed, and the site is still as measured above. In each case I Tabbed to the modified drop zone and pressed Enter, watching for the file chooser:

Change	Reachable by Tab	Enter opens the picker
Add tabindex="0" to the div	yes — 6th stop	no
Add tabindex="0" and role="button"	yes — 6th stop	no
Insert a real <button> that calls click()	yes — 6th stop	yes
Add tabindex="0" plus a keydown handler	yes — 6th stop	yes

That is the crux: tabindex alone gets you focus but not activation. A div has no default action for Enter, and role="button" is an announcement — it does not add behaviour. You need either a real <button> (or a <label> tied to the input) or an explicit key handler.

One more result I cannot give: Space. My key injection never managed to activate a real <button> with Space, even in the control case, so I have no trustworthy Space measurement and I am not going to guess.

How to check it yourself

Questions

Try it: open the converter, press Tab six times and see where you end up.

First published: 4 October 2026