Why Input Buttons Must Have Accessible Names

Input buttons, <input type="button">, <input type="submit">, and <input type="reset">, must expose a discernible accessible name so assistive technologies can communicate their purpose to users.

Unlike <button> elements, input buttons cannot derive a name from inner text. Their accessible name must come from attributes.

What Is an Accessible Name?

When a screen reader encounters a control, it does not analyse what the control looks like on screen. Instead, it reads information from the accessibility tree, a structured representation of the page that the browser exposes to assistive technologies.

An accessible name is the text string associated with a control in that tree. This is what screen readers announce to identify the control.

If the accessible name is empty, users may hear only:

• “Button”
• “Submit button”

with no indication of what action will occur.

Why <input> Buttons Are Different from <button>

<input> elements are void elements in HTML.
They cannot contain children or text content.

<input type="button">   <!-- No inner text possible -->

Because of this:

• There is no text content to derive a name from
• The accessible name must come from attributes such as value or ARIA

By contrast:

<button>Save</button>

The text Save automatically becomes the accessible name.

WCAG Success Criterion

WCAG 4.1.2 – Name, Role, Value

Input buttons are user interface components.
Their name, role, and value must be programmatically determinable.

In practical terms, this means:

Assistive technologies must be able to read the control’s purpose directly from the markup, not infer it visually.

If an input button does not expose a non-empty accessible name, it fails WCAG 4.1.2.

How Accessible Names Are Calculated for Input Buttons

Accessible names are calculated using the Accessible Name and Description Computation (AccName) algorithm defined by the W3C.

In simplified terms, for input buttons, name sources are evaluated in this order:

1. aria-labelledby
2. aria-label
3. value
4. title (fallback only, inconsistent)

The first valid source found becomes the accessible name.

Important: Input buttons cannot get a name from text content because they cannot have children.

Correct Markup Examples

Using value (Preferred)

<input type="button" value="Save changes">
<input type="submit" value="Place order">
<input type="reset" value="Clear form">

The value attribute provides both the visible label and the accessible name.

Using ARIA Labelling (When Needed)

<input type="button" aria-label="Open settings">

<div id="downloadLabel">Download report</div>
<input type="submit" aria-labelledby="downloadLabel">

Use ARIA only when visible text cannot be placed directly on the control.

Prefer aria-labelledby over aria-label when referencing existing visible text.

Using title (Fallback Only)

<input type="button" title="Print page">

This passes automated checks, but:

• title is not reliably announced on focus
• It is not keyboard discoverable
• Screen reader support varies

It should not be used as the primary labelling method.

Incorrect Markup Examples

Missing Name

<input type="button">

No value, no ARIA → no accessible name.

Empty Name

<input type="submit" value="">

An empty value removes the accessible name entirely.

Broken aria-labelledby

<input type="button" aria-labelledby="does-not-exist">

If the referenced element does not exist or has no text, the name resolves to empty.

Default Submit Behaviour

Some user agents expose a default accessible name for:

<input type="submit">

For example, “Submit”.

However:

• This behaviour varies by browser and screen reader
• It is not localizable
• It is fragile and should not be relied on

Always provide an explicit label.

Why <button> Is Usually the Better Choice

In modern development, <button> is almost always preferable because it:

• Supports inner text and rich content
• Handles icons + text naturally
• Avoids naming pitfalls entirely
• Provides better flexibility for design systems

Use <input> buttons only when you specifically need their legacy or form-submission behaviour.

ARIA Overuse Warning

ARIA should not replace native semantics.

Key rules:

• Native labelling first (value)
• Use ARIA only when necessary
• aria-label overrides visible text, use carefully
• aria-labelledby is preferred when visible text exists

Misusing ARIA can create mismatches between what users see and what assistive technologies announce.

Screen Reader Behaviour

When an input button has no accessible name:

• NVDA + Firefox: announces “button”
• VoiceOver + Safari: announces “button”
• JAWS: may announce a default label or nothing useful

Users must then explore surrounding content to guess the action, increasing cognitive load and error risk, especially in forms with multiple submit or reset controls.

Testing Guidance

Automated

• axe, Lighthouse, and similar tools flag this under rules like input-button-name

Manual

1. Inspect the element in browser DevTools → Accessibility pane
2. Check the computed Name
3. Tab to the button using a screen reader
4. Confirm it announces a meaningful label (e.g., “Save changes, button”)

Wrapping Up

• Input buttons cannot derive names from text content
• They must expose a non-empty accessible name via attributes
• value is the most reliable method
• ARIA labelling is valid when used correctly
• Empty or missing names fail WCAG 4.1.2

If an input button’s purpose cannot be determined programmatically, users cannot reliably operate it