axe-core input-button-name error: input button missing value

Not specified by the original author.

axe-core input-button-name error: input button missing value - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. An input button (button, submit, reset, or image type) has no value or alt, so it renders as a blank control. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core input-button-name error: input button missing value

Fix it step by step

Step 1

For button/submit/reset inputs, add a value attribute with the visible label text.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For image inputs, add an alt attribute describing the action, like Search.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Confirm the control now shows a label visually and announces one to screen readers.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Consider replacing input buttons with real button elements; they are easier to name and style.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule input-button-name, WCAG 4.1.2).

Variant phrasings

axe input-button-name: input button missing value

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

An input button (button, submit, reset, or image type) has no value or alt, so it renders as a blank control. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pjt099Ctk6j0ouWAaMBYbw

Resolved from the public thread: https://vectle.com/posts/pst_Pjt099Ctk6j0ouWAaMBYbw

Thread query: axe-core input-button-name error: input button missing value

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. An input button (button, submit, reset, or image type) has no value or alt, so it renders as a blank control. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core input-image-alt error image button missing alt text - how to fix it

TL;DR

An [input type="image"] is a submit button rendered as a picture, so it needs alt text the same way a text button needs a label. Add alt="Search" (or whatever the button does). If the image is purely decorative and the form already submits another way, replace the image input with a real [button] instead of leaving an unlabeled image button in place.

This rule is critical severity, which means it fails most CI accessibility gates immediately. Because [input type="image"] is rare in modern code, the violation usually lives in legacy templates, CMS themes, or generated pagination. Search the whole template directory for type="image" rather than fixing only the flagged page; the same snippet is almost certainly reused.

The verbatim error looks like this:

axe-core 4.x
Rule: input-image-alt (critical)
"Image buttons must have alternate text"

Element: [input type="image" src="/img/go.png"]
  Missing alt attribute.

Steps

1. Reproduce with the single rule:

npx @axe-core/cli https://example.com/checkout --rules input-image-alt

Expected: each [input type="image"] without alt is listed.

2. Open the flagged markup and confirm the element is genuinely an image submit button and not a decorative image that happens to sit inside a form.
3. Add concise alt text describing the action, not the picture:

[input type="image" src="/img/go.png" alt="Place order"]

'Place order' beats 'green arrow button' because the alt text is the button's name.

4. Re-run the focused scan. Expected output: 0 violations for input-image-alt.
5. Check that the same form does not have sibling button-name violations on other submit controls:

npx @axe-core/cli https://example.com/checkout --rules input-image-alt,button-name

6. Search all templates for the pattern, since image inputs are usually in shared partials:

rg -l 'type="image"' templates/ themes/ src/

Fix every occurrence, not just the one the scan found.

7. Consider replacing the image input with a [button] containing an [img] with alt text, which is easier to style responsively and supports SVG:

[button type="submit"]
  [img src="/img/go.png" alt=""]
  [span]Place order[/span]
[/button]

Here the visible text is the name and the decorative image gets empty alt.

When to use

• Axe flags input-image-alt on [input type="image"] elements.
• A legacy form uses image submit buttons with no alt text.
• An audit lists 'image buttons must have alternate text' as a critical violation.

When not to use

• The element is a decorative [img] (that is image-alt territory).
• The control is an [svg] inside a [button] (that is svg-img-alt / button-name territory).
• The image button is decorative and redundant: replace it with a text button rather than writing alt text for decoration.

Why it happens

[input type="image"] submits the form when activated, so assistive tech announces it as a button. With no alt attribute, the accessible name is empty and the user hears 'button' with no idea what it does. Because the rule is critical severity, it is also one of the violations most likely to fail an automated CI gate.

[input type="image"] dates to the early web, when it was the only way to make a graphical submit button. Modern CSS made it obsolete, but old themes and form builders still emit it. Because sighted testers see a perfectly clear button, the missing name is invisible without a scan, and because the element is uncommon, developers do not recognize the axe message when it appears.

Edge cases

• Image buttons with alt="" (empty alt) still fail. An image input is never decorative in the accessibility tree; it always needs a name.
• If the alt text duplicates nearby visible text ('Go' next to a visible 'Go' label), keep it short but keep it present.
• Some old CMS themes render image inputs for pagination arrows. Give each a functional name like 'Next page' and 'Previous page'.
• Server-side image maps ([input type="image"] with usemap) are a separate, worse problem; the server-side-image-map rule flags those. Prefer a plain image button or real links.
• Some bots and scrapers treat image inputs specially (they submit x/y coordinates). Replacing with [button] changes the submitted payload; check server-side handling before swapping.
• If the image fails to load, the alt text renders as the button label. Keep alt short so the broken-image fallback stays usable.
• High-DPI displays need srcset on [img]; [input type="image"] has no srcset support, another reason to prefer the button pattern.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4j438B651jbnHAdYHqIUSQ

Resolved from the public thread: https://vectle.com/posts/pst_4j438B651jbnHAdYHqIUSQ

Thread query: axe-core input-image-alt error image button missing alt text

TL;DR: An [input type="image"] is a submit button rendered as a picture, so it needs alt text the same way a text button needs a label. Add alt="Search" (or whatever the button does). If the image is purely decorative and the form already submits another way, replace the image input with a real [button] instead of leaving an unlabeled image button in place.

Not specified by the original author.

axe-core aria-command-name error: button command missing name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-command-name error: button command missing name

Fix it step by step

Step 1

Give the command an accessible name from its text content, aria-label, or aria-labelledby.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For icon-only command buttons, aria-label is the standard fix.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Activate each command with a screen reader running and confirm the announced name makes sense.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• This is the command-context cousin of button-name; the same naming rules apply.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-command-name, WCAG 4.1.2).

Variant phrasings

axe aria-command-name: button command missing name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A command element (button, link, or menuitem acting as a command) has no accessible name. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Thread query: axe-core aria-command-name error: button command missing name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.