input-button-name
Web validation
HTML <input> elements whose type attribute is button, submit, or reset need a programmatically determinable name so assistive technologies can announce their purpose. When the name is missing, people who use screen readers, voice control, or other assistive tools are left guessing, which can make forms impossible to complete.
Pass Patterns
Using the value attribute
The visible label is provided directly in the control, so AT can expose it as the accessible name.
<input type="submit" value="Search" />Using aria-label
An explicit ARIA label supplies a descriptive name even when no text is visible.
<input type="button" aria-label="Play" />Default label
<input> of type="reset" or type="submit" has an implicit label even if not specified.
<input type="reset" />
<input type="submit" />Fail Patterns
Missing name
With no value, aria-label, or aria-labelledby, the control does not announce its purpose.
<input type="button" />Reference to an absent label
Pointing aria-labelledby to a non-existent element leaves the name empty.
<input type="button" aria-labelledby="does-not-exist" />WCAG techniques
Sufficient techniques
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- ARIA14: Using aria-label to provide an accessible name where a visible label cannot be used
Failure techniques
ACT Rules
Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Load the page, open a screen reader.
- Move to the button with Tab.
- Listen to what the screen reader announces.
Expected result: It speaks the button’s name (“Play,” “Search,” and so on).
Actual result: It announces “button”, “unnamed button” or nothing at all.
Inspecting the browser dev-tools
- Open the Accessibility Tree panel.
- Select the input element.
Expected result: The Name field shows the text you provided.
Actual result: If unnamed, Name is empty.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires every user-interface component to expose a name and role that assistive technologies can retrieve. An input button without an accessible name fails this requirement because its purpose cannot be programmatically determined.
Why is this issue marked as Critical?
Without an accessible name, input buttons are invisible to screen readers and unusable with voice commands. The resulting barrier blocks form submission, navigation, and task completion for people who rely on assistive technology, so the impact is severe across browsers and platforms.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.22(a) | A text equivalent for every non-text element shall be provided (e.g., via “`alt`”, “`longdesc`”, or in-element content). |
| 508 Trusted Tester | 1.3.1-programmatic-label, 5.C | The combination of the accessible name, accessible description, and other programmatic associations (e.g., table column and/or row associations) describes each input field and includes all relevant instructions and cues (textual and graphical). |