( Perceivable / WCAG 1.1.1 )

Image input is missing alt text

SeriousLevel AWCAG 1.1.1 — Non-text Content

What is this issue?

<input type="image"> is a genuine HTML form control: clicking it submits the enclosing form, the same as <button type="submit">, while rendering a specified image in place of the default button chrome. This element has no alt attribute, so it has no accessible name, the text a screen reader announces to identify an element, drawn from the first source that applies: aria-labelledby, then aria-label, then alt, then other fallbacks specific to the element type.

Because this is a functional control, not a decorative or purely informative image, the missing name is a missing button label, not just a missing picture description.

Why does this matter?

An <input type="image"> is functionally a button. When it has no accessible name, a screen reader announces only its role (“button”), with nothing telling the user what submitting the form at that point will actually do. On a checkout page, that ambiguity turns a routine “place order” click into a guess about whether the button is safe to activate.

A search form using a magnifying-glass icon as an <input type="image"> with no alt announces as “button” alone. A sighted user recognizes the icon instantly; a screen reader user has no way to distinguish it from any other unlabelled button on the page without exploring the surrounding markup first.

Who is affected?

  • Screen reader users hear a generic “button” announcement with no indication of what submitting the form at that control will do, forcing them to guess or explore the page for context before activating it.
  • Voice control users operate controls by speaking their accessible name, such as “click Search”; with no name to match against, an <input type="image"> can’t be targeted by voice at all.

What users experience

Renata uses Dragon voice control software to check out on an online store after a repetitive strain injury made typing and clicking painful for her. She says “click submit order,” but the checkout button is an <input type="image"> with no alt text, so voice control shows no matching target on screen. She has to fall back to guessing a generic phrase like “click button” and hope only one button exists on the page, or ask someone else to complete the purchase for her.

How do I fix it?

Add alt text to the <input type="image"> describing the action it performs when clicked (“Search,” “Place order,” “Submit”), the same way you’d write the visible text on an equivalent <button>. This works because alt is the accessible-name source for input type="image" elements specifically, resolved the same way an <img>’s alt is, and it’s the only reliable naming method every screen reader and voice control tool already knows how to use.

Write the alt value as an action, not an image description, since the element’s actual job is submitting a form: “Search” tells a screen reader user what will happen, while “magnifying glass icon” only describes what it looks like.

Code Examples

Before
<input type="image" src="/icons/search.svg">
After
<input type="image" src="/icons/search.svg" alt="Search">

The fix adds one attribute, but the value matters as much as its presence: alt="Search" tells a screen reader or voice control user exactly what activating the control does, matching the icon’s visual meaning without describing its shape.

Common Mistakes

Mistake: “This is basically an image, so it needs the same alt text an img would get.” Because this element also acts as a form submit button, its alt needs to describe the action it triggers, not the picture rendered on it, the same distinction that applies to any functional image inside a link or button. “Magnifying glass icon” describes the graphic; “Search” describes what happens.

Mistake: “The form’s other fields already make the purpose obvious, so this button doesn’t need its own label.” Every control needs its own accessible name regardless of surrounding context, since a screen reader user tabbing directly to a button has no guarantee they’ve already encountered the rest of the form in order, and a voice control user targeting this specific button by name has nothing to say without one.

Mistake: “A visible caption underneath the image already explains what it does.” A visible caption has no programmatic connection to the input element itself unless it’s explicitly linked, and even then, input type="image" doesn’t support the wrapping-label pattern regular text inputs do. The alt attribute is the only reliable naming path for this specific element.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. This page’s ruleId, redflag-input-image-alt, is a docs-only alias: src/lib/wcagData.js’s DOCS_URL_MAP redirects the underlying axe-core rule input-image-alt to this redflag-prefixed docs slug so the extension’s “View docs” link resolves correctly. The detection logic itself is unmodified, stock axe-core. axe-core calls the check as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set, and inspects every input[type="image"] element for a non-empty accessible name via alt, aria-label, or aria-labelledby.

False negative: axe-core confirms alt text exists; it cannot judge whether it describes the actual action. alt="image" on a checkout submit button passes the check while telling the user nothing about what it does. False positive: none typical for this check, since resolving to a non-empty accessible name is a binary condition axe-core evaluates reliably. Manual step: confirm the alt text states the correct action for that specific button, especially on pages with more than one input type="image" control.

Manual Testing

  1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
  2. Tab to the input type="image" control.
  3. Listen to what’s announced: it should be a specific action name followed by the role (“Search, button”), not just “button” alone.
  4. If the announcement is only the generic role with no name, the check fails.

1.1.1 Non-text Content: All non-text content must have a text alternative that serves the equivalent purpose. A missing alt on input type="image" fails this criterion directly.

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and value. An unlabelled input type="image" has a role (button, from its type) but no name, which is what makes this rule a 4.1.2 failure as well as a 1.1.1 one.

Image is missing alt text is the equivalent missing-text-alternative failure on a plain <img> rather than a functional form control.

Image map area element is missing alt text and Object element has no text alternative cover the same naming failure on two other non-text element types axe-core checks separately.

Alt text is a filename or placeholder is the next failure mode past this one: alt text that exists but is generic junk instead of a real action description.

Alt text is a raw filename covers the equivalent quality problem when a form control’s only label ends up being a filename-like string.

References

Frequently asked questions

Is an input type="image" the same thing as a button with a background image?

No. input type="image" is a genuine form submit control that also displays an image in place of the default button appearance; clicking it submits the form, including the x and y coordinates of the click. A styled button with a CSS background image is a different element with a completely different naming mechanism.

Should the alt text describe the picture or the action?

The action. Because input type="image" functions as a submit button, its alt text should say what happens when it is activated, such as "Submit search" or "Place order," not describe the icon or picture used to render it visually.

Does title work as a fallback if alt is missing?

Only inconsistently. Some browsers will fall back to title if alt is entirely absent, but support varies, and title never reaches keyboard-only or touch users as anything more than a hover tooltip. Always set alt directly rather than relying on a fallback.

Is this the same axe-core check as image-alt?

No, they are separate rules for separate elements. image-alt checks plain img elements; this page's check, input-image-alt, specifically inspects input elements with type="image", since form controls have their own distinct accessible-name resolution rules.