Image input buttons need alt text

Image input buttons must have alt text describing purpose

Every image input (<input type=image>) needs alt text that states its function. This pattern appears on forms that use a graphic for submit, search, or upload. Without a clear name, people using assistive tech cannot tell what the control does.

Why It Matters

When alt text is missing, screen readers announce an unlabeled button or only say “button,” forcing users to guess. This slows form completion and leads to errors.

Users of screen readers and braille displays rely on the control’s programmatic name. Speech input users also need a visible label reflected in the accessible name to activate the control by voice. This aligns with WCAG 2.2 expectations for non-text content and control names.

Common Causes

• No alt attribute on input type=image.
• Empty alt (alt="") used on a functional control.
• Using the filename or a vague word (e.g., “image”, “icon”) as the alt text.
• Relying on nearby text or a title tooltip instead of a programmatic name.
• Multiple image buttons with identical alt text that do different things.
• Using a decorative graphic as an input when a standard button with text is appropriate.

How to Fix

1. Find all image inputs:
   • Search your codebase for input[type="image"].
2. Provide a meaningful accessible name:
   • Prefer alt with a concise verb and object that reflects the action (e.g., “Search”, “Submit order”, “Upload photo”).
   • aria-label or aria-labelledby may be used, but alt is the native naming mechanism for image inputs.
3. Match visible text when present (recommendation):
   • If the graphic contains words, include those words in the accessible name so speech users can reference it.
4. Differentiate multiple actions:
   • Use distinct names like “Save draft” vs “Publish post,” not just “Submit”.
5. Avoid decorative image inputs:
   • If the graphic is purely decorative, do not use input type=image. Use a <button> with text and apply the image via CSS or include an <img> marked decorative alongside visible text.
6. Localize the name:
   • Translate alt/ARIA to the page’s language.

How to Test

Keyboard

• Tab to each image button; it should receive focus and activate with Enter/Space.
• While focused, ensure a visible label exists somewhere nearby for sighted keyboard users.

Screen reader

• With NVDA/JAWS/VoiceOver, navigate to the control. It should announce a descriptive name plus role (e.g., “Search, button”).
• Open the screen reader’s elements list for buttons/controls and confirm each image button has a unique, meaningful name.

Mobile/touch

• With TalkBack or VoiceOver, swipe to the control. It should announce the intended action and role.

Accessibility tree

• In browser devtools, inspect the node and verify the Name reflects the action. If the name is empty or a filename, fix the source attributes.

Good Example

<form action="/search" method="get">
  <label for="q">Search the site</label>
  <input id="q" name="q" type="search">
  <input type="image" src="/assets/icons/search.svg" alt="Search">
</form>

Bad Example

<input type="image" src="/img/submit.png">
<input type="image" src="/img/submit.png" alt="submit.png">
<input type="image" src="/img/icon.png" alt="image">

Quick Checklist

• Every input type=image has a non-empty accessible name.
• alt succinctly describes the action (verb + object when helpful).
• aria-label/aria-labelledby used only when alt isn’t practical; result is still clear.
• Names are unique when multiple image buttons are present.
• Visible words in the graphic are included in the name (recommendation).
• Decorative graphics are not used as input type=image.
• Name is localized to the page’s language and verified in the accessibility tree.