Input button has no accessible name

What is this issue?

An <input> element with type="submit", type="button", or type="reset" has no value attribute, or the attribute is present but empty. For these three input types, the browser renders the value attribute’s text as the button’s visible label and uses that same text as its accessible name, since there’s no separate text content the way a <button> element has; <input> is a self-closing, void element with nothing between an opening and closing tag.

Without value, some browsers fall back to a generic default like “Submit” or “Submit Query,” but that fallback is inconsistent across browsers and inputs, and an empty value="" string produces no fallback at all: a completely silent control.

Why does this matter?

A submit button with no name is fully clickable for a sighted mouse user, who can see its shape, size, and position even with no visible text. That’s exactly what makes this bug dangerous: it passes casual visual testing every time, because nothing looks obviously broken on screen, while a screen reader or voice control user hits a dead end.

For a screen reader user tabbing through a checkout form, an unnamed submit button announces only “button” at the exact moment they need to confirm they’ve reached the final action. They have no way to distinguish it from any other unnamed control on the page, and pressing an unidentified button that finalizes a purchase or deletes data is not a risk most people are willing to take on a guess.

Who is affected?

• Screen reader users hear only “button” with no indication of what pressing it does, at the point in a form where confirming the right action matters most.
• Voice control users operate a page by speaking a control’s visible or accessible name, such as “click Submit order.” With no name to match, the button can’t be targeted by voice at all, regardless of how obvious its position looks on screen.

What users experience

Amara uses NVDA on her Windows laptop to complete a multi-step checkout. She fills in her shipping details and tabs to what should be the “Continue to payment” button, a JavaScript-rendered <input type="submit"> with no value set because a developer assumed the CSS-styled label text next to it would be announced instead. NVDA says only “button.” She backs up, arrows through the surrounding text hoping to confirm she’s found the right control, and only proceeds after guessing it’s safe, a step no sighted user of the same form has to take.

How do I fix it?

Set a value attribute with text that describes the button’s action. This works because the browser uses value as both the visible label and, through the standard accessible-name computation, the announced name: one attribute does both jobs for these input types.

Write the value the same way you’d write any button’s visible text: a short verb phrase naming the action, like “Create account” or “Continue to payment,” not a vague placeholder like “Submit” that gives no hint what happens next. If you need the accessible name to differ from the visible label for some reason, aria-label overrides value for assistive technology while leaving the visible text unchanged, but for this input type, matching the two is almost always simpler and safer.

Code Examples

<input type="submit">
<input type="button" value="">
<input type="reset" onclick="clearForm()">

<input type="submit" value="Create account">
<input type="button" value="Add another item" onclick="addItem()">
<input type="reset" value="Clear form" onclick="clearForm()">

Each value now describes the specific action the control performs instead of leaving it blank or generic. The browser renders this same string as the button’s visible text, so sighted and non-sighted users hear and see the identical, accurate name.

Common Mistakes

Mistake: “There’s visible text next to the button in the design, so it’s labeled.” Text placed near an <input type="submit"> in the layout has no programmatic connection to it: the accessible name computation for this input type looks only at value (or aria-label/aria-labelledby if present), never at nearby unrelated text. Visual proximity does nothing for the DOM relationship assistive technology depends on.

Mistake: “The button works fine when I click it, so it must be accessible.” A mouse click test only verifies the control is functional, not that it’s identifiable. An unnamed submit button submits the form perfectly for a sighted user who can see and target its shape; the failure is entirely invisible until someone relies on a screen reader or voice command instead of a mouse.

Mistake: “I’ll just switch to a <button> element since it’s more modern.” Switching element types is a valid fix, but only if you also add text content or aria-label to the new <button>. The underlying mistake, an unnamed control, follows you to any element type if you don’t actually name it. There’s no element choice that fixes this problem by itself.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s input-button-name rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects every <input> element with type="submit", type="button", or type="reset" and checks whether it resolves a non-empty accessible name from value, aria-label, or aria-labelledby; a missing or empty value with no ARIA override is flagged.

False negative: axe-core confirms a name exists; it can’t tell whether a generic value="Submit" is meaningfully descriptive for its specific form, so a technically-named but vague submit button on every form across a site passes this automated check. 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: read the announced name of every input button against the action it actually performs, and confirm the two match; the automated check only proves a name exists, not that it’s the right one.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or JAWS running.
2. Tab to every <input type="submit">, <input type="button">, or <input type="reset"> on the page, most commonly form submit buttons.
3. Listen to what’s announced: it should be a specific action (“Create account, button”), not the generic fallback some browsers show (“Submit, button”) and not the bare role alone (“button”).
4. Open the browser’s accessibility inspector (Chrome DevTools → Elements → Accessibility pane) on the input and confirm its “Name” property is set and matches the intended action.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. An input button with no value has a role (from its type) but no name, failing 4.1.2 on the naming requirement specifically; it is the primary criterion this rule maps to.

Related Issues

Button or link has no accessible name is the same underlying failure on <button> and <a> elements, where empty text content causes the missing name instead of an empty value attribute.

Custom control built with an ARIA command role has no accessible name extends the same requirement to custom widgets built with role="button" on a non-native element.

Custom form field built with ARIA has no accessible name covers the parallel naming failure for ARIA-based text inputs and comboboxes rather than native <input> buttons.

Interactive element has no accessible name at all is RedFlag’s broader AI-assisted check for missing names across custom interactive components beyond native HTML form controls.

Form input has no label covers the equivalent naming failure for text-entry inputs, using a different HTML mechanism (labels, not value) to fix the same underlying “no accessible name” problem.

References

• W3C Understanding 4.1.2: Name, Role, Value
• W3C Technique H91: Using HTML form controls and links
• MDN: input type=“submit”