Image Button Needs Alt: How to Fix It

What this check flags — and why it matters

An image button is a form control that doubles as a graphic: it submits the form like any submit button but renders as an image instead of text. Because the label lives inside the picture, assistive tech has no text to read unless you supply one. The axe-core input-image-alt rule flags any image button missing that text. It’s a critical-severity check mapping to two WCAG criteria — 1.1.1 Non-text Content (Level A) and 4.1.2 Name, Role, Value (Level A) — because an image button is both non-text content and an interactive control, so a nameless one is a control a keyboard or screen-reader user cannot confidently operate.

A real failing example

A search form using a magnifying-glass graphic as its submit control, with no alt:

<form action="/search">
  <input type="text" name="q">
  <input type="image" src="/icons/search.png">
</form>

A screen reader reaches that control and announces something like “button” — or nothing useful — leaving the user guessing whether it searches, submits, or resets. Give it alt that names the action, not the picture:

<form action="/search">
  <input type="text" name="q">
  <input type="image" src="/icons/search.png" alt="Search">
</form>

Now the control announces “Search, button.” The accessible name can also come from aria-label or an aria-labelledby pointing at visible text, but a plain non-empty alt is the simplest and most robust choice.

Write alt for the action, not the artwork

The user does not care that the icon is an envelope. They care that clicking it sends the message. Alt on a button is a functional label, and W3C technique F65 documents exactly this failure — an image button submitting a form with no text alternative.

How to detect it

1. Screaming Frog — use a custom extraction with the XPath //input[@type='image' and (not(@alt) or @alt='')] to list every image button missing alt across the whole site in one crawl.
2. axe DevTools — run the extension and look for the critical input-image-alt violation. It highlights each offending control in the DOM.
3. Lighthouse — the Accessibility audit includes an image-button alt check; a failing control shows up with the exact node listed.
4. View Source / DevTools — search the HTML for type="image" and confirm each one has a non-empty alt, aria-label, or aria-labelledby. Any that don’t are the failures.

How to fix it

1. Locate every <input type="image"> on the site.
2. Add an alt that describes what the button does when clicked — “Search,” “Submit order,” “Log in” — not what the picture looks like.
3. If the label is genuinely visible elsewhere, you may point at it with aria-labelledby instead, but a direct alt is usually cleaner.
4. Never set alt="" on an image button. Empty alt means decorative, and a control that submits a form is never decorative.
5. Re-run axe to confirm the critical input-image-alt flag is cleared.

Where you can, consider replacing <input type="image"> with a <button> containing an <img> or an inline SVG — it gives you more styling control and a clearer path to an accessible name. But the immediate fix is simply the missing alt.

One caution when auditing at scale: image buttons hide in the corners of a site — a search box in the header, a newsletter arrow in the footer, a legacy contact form nobody has touched in years. A single homepage check will miss them, so crawl the whole property rather than spot-checking a few templates. The controls most likely to be nameless are exactly the ones built long ago and never revisited, and they are often the ones on your highest-traffic paths.

Common mistakes

• Describing the icon. “Magnifying glass” tells the user what they can’t see anyway. Name the action: “Search.”
• Using alt="" to silence the warning. Empty alt marks the image decorative, which is wrong for a submit control and leaves the button nameless. It swaps one failure for another.
• Relying on the title attribute. title is not a reliable accessible name and is invisible to many users. Use alt.

FAQ

Can I use aria-label instead of alt?

Yes — aria-label or aria-labelledby both supply an accessible name and satisfy the rule. But for an <input type="image">, a plain non-empty alt is the most robust and widely supported option, so reach for that first.

Why is this rated critical?

A nameless submit button blocks a core task — a screen-reader user literally cannot tell what the control does before activating it. That’s a task-blocking barrier, which is why axe scores it critical rather than minor.

What should the alt actually say?

The action the button performs, in a few words: “Search,” “Add to cart,” “Subscribe.” Match the language a sighted user would infer from the button’s position and the form around it.

Is this the same as a regular unlabeled button?

It’s a close cousin. Standard <button> and text-input buttons have their own naming checks — see input buttons must have discernible text and buttons must have discernible text. This rule is specific to image-type inputs.

How does this relate to redundant alt on linked images?

Opposite ends of the same idea. An image button needs alt because nothing else names it; a linked image beside a text label should have empty alt to avoid repeating that label. See alt repeats link text.