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
- Give every image button an
altthat names the action – "Search", "Subscribe", "Pay with card" – not the picture ("magnifying glass"). - Keep it consistent with any visible text next to it, so voice-control users can say what they see.
- 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
- Find the image buttons: in developer tools, search the Elements panel for
type="image". - 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.
- Ask: without the picture, does that name tell you what happens when you press the button?
- Try it with a screen reader (NVDA or VoiceOver): tab to the button and listen. With voice control, say "click" followed by the name.
Related WCAG criterion
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.