Image button without alt text (input-image-alt)

The input-image-alt rule flags image buttons – <input type="image"> – that have no text alternative. A screen reader then announces only "button", or the image's file name, and nobody can tell whether it searches, submits an order or signs them up. The fix is an alt that names the action, such as alt="Search".

What the rule means

An <input type="image"> is a submit button drawn as a picture. Its text alternative is the button's name, so two criteria apply: 1.1.1 Non-text Content needs an alternative for the image, and 4.1.2 Name, Role, Value needs every control to have a name.

axe accepts a non-empty alt, aria-label, aria-labelledby or a title attribute. Unlike a normal image, alt="" is not allowed here: an empty alternative would tell assistive technology to ignore a button that does something, so axe reports it.

axe does not judge the words. alt="magnifier.png" or alt="Go" next to three other "Go" buttons passes the rule. Whether the name says what the button does is a human judgement.

Who is affected

Blind people using a screen reader hear "button" with no hint of its purpose, or a file name such as "btn underscore submit". People using voice control cannot say "click Search" when the button has no name to match. People who switch off images, or whose connection fails to load them, see an empty box or the alternative text – which then has to make sense on its own.

Why the check fails

  • Search forms with a magnifier icon as <input type="image"> and nothing else.
  • Older newsletter, login and contact forms from form plugins or hand-built templates that predate <button> styling.
  • Payment and "Buy now" buttons embedded as image inputs from third-party snippets.
  • An empty alt="" added to silence a linter, which is right for decoration and wrong for a button.
  • Templates that pass the image's file name into the markup but not an alternative text field.

How to fix it

  1. Give every image button an alt that names the action – "Search", "Subscribe", "Pay with card" – not the picture ("magnifying glass").
  2. Keep it consistent with any visible text next to it, so voice-control users can say what they see.
  3. Better still, replace the image input with a real <button>: it is easier to style, and it takes text as well as an icon.
<!-- Before: the image button has no text alternative -->
<form class="site-search" role="search" action="/search/">
  <input type="search" name="q" aria-label="Search the site">
  <input type="image" src="/icons/magnifier.svg" width="24" height="24">
</form>
<!-- After: alt names what the button does -->
<form class="site-search" role="search" action="/search/">
  <input type="search" name="q" aria-label="Search the site">
  <input type="image" src="/icons/magnifier.svg" width="24" height="24" alt="Search">
</form>

The same form with a <button> instead – the icon is decorative, the button's name comes from its text:

<button type="submit" class="site-search__submit">
  <img src="/icons/magnifier.svg" width="24" height="24" alt="">
  <span class="visually-hidden">Search</span>
</button>

How to test it manually

  1. Find the image buttons: in developer tools, search the Elements panel for type="image".
  2. Select each one and open the Accessibility pane (Chrome, Edge) or the accessibility inspector (Firefox). The "Name" row shows what a screen reader will announce.
  3. Ask: without the picture, does that name tell you what happens when you press the button?
  4. Try it with a screen reader (NVDA or VoiceOver): tab to the button and listen. With voice control, say "click" followed by the name.

1.1.1 Non-text Content and 4.1.2 Name, Role, Value, both Level A. Related: 2.5.3 Label in Name when visible text sits next to the button, and 2.4.6 Headings and Labels for names that are there but say nothing.

How Reviseberg reports it

Reviseberg runs input-image-alt on every crawled page at 1280px. The issue list shows the rule with its severity, both WCAG criteria and their level, the number of buttons and pages affected, and the points you get back by fixing it. A search form in the header appears on every page, so one fix in the template clears all of them; the detail view gives the CSS selector, the HTML snippet and each affected page.

You can mark a finding as "ignore", "can't fix" – for example a payment button a provider controls – or "false positive", with a reason; every decision is logged. A clean result here never marks 1.1.1 or 4.1.2 as passed: whether a name is meaningful is for a person to confirm.

  • undefined – ordinary images without a text alternative.
  • undefined – <button> elements with no accessible name.
  • undefined – <input type="submit"> and similar buttons without text.

Find unnamed buttons across your site – get a free scan

Frequently asked questions

Why is alt="" wrong here when it is fine on an img?

Because an empty alternative means "ignore this", and a button always does something. On a decorative <img> that is exactly what you want; on an image button it hides a working control.

Should the alt text describe the icon?

No. It names the action. "Search" is right; "magnifying glass" describes a picture nobody needs described.

Is a title attribute enough?

axe accepts it, and the button then has a name. A title only appears on mouse hover, though, so an alt is the more reliable choice.

Should I stop using input type="image"?

It is still valid HTML. A <button> with text or an icon plus hidden text is usually easier to style and maintain, and harder to get wrong.

Sources

  1. W3C, Understanding SC 1.1.1 Non-text Content – https://www.w3.org/WAI/WCAG22/Understanding/non-text-content
  2. W3C, Understanding SC 4.1.2 Name, Role, Value – https://www.w3.org/WAI/WCAG22/Understanding/name-role-value
  3. Deque University, axe-core 4.13 rule input-image-alt – https://dequeuniversity.com/rules/axe/4.13/input-image-alt
  4. W3C, WCAG Technique H36: Using alt attributes on images used as submit buttons – https://www.w3.org/WAI/WCAG22/Techniques/html/H36
  5. MDN, <input type="image"> – https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/image

See what a scan finds on your site

One page in about thirty seconds, no email needed. The full report covers up to 100 pages and a keyboard journey.