File upload: accessible browse + drag-and-drop

Minimum viable pattern

• Use a real <input type="file"> with a visible <label>.
• Show requirements as text: file types (e.g., PNG/JPG/PDF), max size, and max count.
• Keep an explicit action (e.g., Upload) so people can review before sending.
• List the selected filenames so there’s a clear confirmation.
• Handle errors inline with aria-invalid + aria-describedby.

Accessibility details that matter

• Keyboard discovery: the primary control must be reachable with Tab and activatable with Enter/Space.
• Don’t hide the only control behind drag-and-drop. Drag-and-drop is optional; browsing is required.
• Status without spam: one polite role="status" message per selection/error is often enough.
• Focus stability: avoid stealing focus after selection; let people decide what to do next.

Drag-and-drop notes

• Make the drop target a label for the file input, so it also works as a “Browse…” control.
• Prevent default on dragover and drop so the browser doesn’t navigate away.
• Validate what you receive: accept filters help, but you still need server-side checks.

If you support multiple files, consider per-file errors (type/size) rather than one generic message.

Mobile considerations

• Camera / gallery flows: many people upload by taking a photo; keep instructions short and visible.
• Large touch targets: make the “Browse…” affordance a clear button-like element.
• Unreliable drag-and-drop: on mobile, drag-and-drop may not exist—so the picker is the core path.

Common pitfalls

• Clickable <div> with no keyboard support (“just drop it”).
• Requirements hidden until after an error (“Upload failed”).
• Only color changes for errors, no text.
• Status announced constantly (per drag event, per progress tick) instead of meaningful checkpoints.