Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Accessibility · WCAG 4.1.2 level A

Input Buttons Must Have Discernible Text: Identify the Action

Name input button, submit and reset controls. Use clear captions, preserve submitted values, inspect ARIA overrides, and test actions and localisation.

Published · Updated

What the check tests

Check
a11y.axe.input-button-name - Input buttons must have discernible text
Passes when
Ensure input buttons have discernible text
Scope
graded on every page crawled
Conformance
WCAG level A
Fix effort
small - under an hour

In one paragraph

Input buttons must have discernible text means an applicable button-like input did not expose a name accepted by this rule. Provide a clear action caption through its appropriate native value or another supported naming mechanism. Inspect the visible and computed wording together. Browser defaults can name submit or reset inputs in some cases, but an automated pass does not prove the wording explains the actual task.

Why it matters

For input button, submit, and reset types, value commonly supplies the displayed caption and accessible name unless another naming source takes precedence. An explicit empty value can leave a button visually blank, especially when CSS adds only an icon.

Submit and reset inputs can receive localised browser default captions when value is omitted. A plain button input has no equivalent assumed action text. Do not promise every user hears an English Submit or treat a generic browser label as adequate explanation for a sensitive transaction.

The action matters. Send request, Pay now, and Clear answers are different outcomes even if all are valid non-empty captions. A reset control can be particularly disruptive if users do not understand that it clears their entries.

How WebAuditOS evaluates this finding

The supplied input-button-name rule checks applicable native input button, submit, and reset elements. It recognises native captions and documented ARIA, title, or label naming paths, with applicability exceptions. Image inputs and native button elements have neighbouring rules.

Critical impact maps to high severity. A presentational exception is not advice to remove the semantics of a real active control. The check does not verify meaningful wording, visible consistency, safe actions, or the rest of the form.

How to fix it

  1. Identify the precise input type and real action. Inspect how the server or client decides which submission path to run and whether the control's value is also functional application data.
  2. Supply a useful caption. For example:
<input type="submit" value="Send request" name="sendRequest">

The form's actual endpoint, validation, privacy information, and feedback remain separate responsibilities.

  1. Prefer explicit appropriate language rather than relying on a generic browser default when the action needs specificity. A payment or destructive reset should not be described as an unrelated harmless step.
  2. Review aria-label and aria-labelledby precedence. If the visible value says Send request but the computed name says Delete record, a non-empty test can pass while the interface is misleading.
  3. Do not rely on a background icon or CSS-generated caption alone to supply a robust name. If a graphical action is required, choose an appropriate tested native or ARIA naming strategy and keep the meaning available.
  4. Preserve backend contracts when changing value. Some forms submit a named button's value to select a server action, so a wording edit may require coordinated application changes or a better separation of internal and human identifiers.
  5. Test keyboard activation, focus visibility, error handling, successful submission, and intentional reset behaviour. Check translated and mobile versions as well as the initial desktop view.
  6. Rescan the matching naming rules and manually review action clarity. A blank button with only a hidden name may still be poor visible design even if it satisfies this rule.

What the fix can break

An explicit empty caption can override a useful default, while a translated caption can accidentally change functional data. Inspect both accessibility and form submission consequences.

Changing an input to button can affect default type, submitted values, styling, and event handlers. Preserve real behaviour rather than selecting an element solely for easier visuals.

Do not use role=none to make an active action disappear from a naming rule. Users still need to identify and operate the control.

Questions

Why can an omitted submit value pass while an empty one fails?

The supplied rule recognises browser default naming for the omitted case. An explicit empty value changes that input's caption behaviour.

Does this rule cover input type=image?

No. The supplied integration exposes a separate image-button alternative-text rule.

Can changing visible value affect the backend?

Yes, in forms that use the submitted button value as action data. Verify that contract before editing.

Review button names, image-button alternatives, and the automation limits guide.

What severity does this get in the report?

High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core 4.13.0, so a failure arrives as high - which is why the panel above states a conformance level rather than a severity.

Standards and sources

In the report

Test this on your own site

Every scan runs a11y.axe.input-button-name on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.