Input Buttons Must Have Discernible Text: How to Fix It

This check flags an <input> button, type submit, button, reset, or image, that exposes no text a screen reader can announce. The user hears "button" and nothing more, so on a form the make-or-break action, "Submit," "Pay now," "Search," becomes a mystery box they have to guess at. This one sits right on the conversion path: an unnamed submit button on a lead or checkout form is about as expensive as an accessibility defect gets.

Why input buttons name themselves differently

The confusing part of this rule is that the <input> button types do not take their name the way people expect. A <button> element reads its name from the text you put between its tags, which is intuitive. An <input type="submit"> has no children, it is a void element, so there is no "between the tags" to hold text. Its label and its accessible name both come from the value attribute. Leave value empty and you get a button that may still render, browsers supply a default face like "Submit" for submit types, but that default is not guaranteed to be exposed as a reliable accessible name across assistive tech, and it certainly will not match your intended wording. The image type is a different animal again: it behaves like a graphical submit button, so it needs an alt attribute exactly the way an image does. One control, three naming rules depending on the type, which is why a form can pass a quick visual review and still fail this check on half its buttons.

A real failure, and the fix

The classic version is an image submit button with no fallback text, styled to look like a "Search" button:

<input type="image" src="/img/search-btn.png">
<input type="submit" value="">

The image button has no alt, and the submit button's value is empty, so both announce as bare buttons. Add discernible text to each, an alt on the image type and a real value on the submit type:

<input type="image" src="/img/search-btn.png" alt="Search">
<input type="submit" value="Create account">

Now they announce "Search, button" and "Create account, button," and the purpose is obvious without sight of the styling.

Where the name comes from, by input type

How to detect it

1. axe DevTools: run the extension; "Input buttons must have discernible text" flags each button and shows whether value, alt, or an ARIA name is missing.
2. Lighthouse: run the Accessibility audit in Chrome DevTools and read the "Names and labels" group, where buttons without an accessible name are listed.
3. WAVE: load WAVE and look for the "Missing form label" or empty-button alert sitting on the control.
4. Manual check: tab to each button with a screen reader running; if it announces "button" with no words attached, the discernible text is missing.

How to fix it

For submit, button, and reset inputs, set a clear value that states the action, because value is both the visible label and the accessible name. For type="image", add an alt that describes the action, not the picture, "Search" rather than "magnifying glass." Use aria-label only when you genuinely cannot show text, and keep it action-first. If you have the freedom to change the markup, a <button>Submit</button> with real text between the tags is the most robust option, covered in buttons must have discernible text. Image submit buttons also intersect with image button needs alt, and the fields those buttons submit are covered in form input elements must have labels.

Write the label as the action, not as a generic acknowledgement. "Create account," "Send message," and "Apply filters" tell a user exactly what happens when they press the button, while "Submit," "OK," and "Go" force them to infer it from context they may not have. This is a small copy change with an outsized payoff, because it helps everyone, not only screen reader users, and it costs nothing to ship. Watch for two failure patterns while you are in there: buttons that were styled entirely with a CSS background image and given an empty value, which announce as silent buttons, and duplicated form partials that stamp the same nameless button onto every row of a repeated section. Fix the template once and the whole set clears at the same time.

Frequently asked questions

What is the difference between this and the button-element check?

This rule targets the <input> button types, where the name comes from value or alt. The <button> element takes its name from the text between its tags instead, so the fix differs even though the goal is the same.

Does a background-image button pass?

Only if it still has real text. A button styled entirely with a CSS background image and an empty value announces as nothing, so give it a value or an aria-label.

Is title a valid substitute for value?

Do not rely on it. title support is inconsistent and it does not display for touch or keyboard users. Use value, alt, or aria-label so the name is dependable.

Which success criterion covers unnamed buttons?

This maps to WCAG 4.1.2 Name, Role, Value (Level A), which requires every interactive control to expose a programmatic name describing its function. A submit button with an empty value has a role but no name, so it falls short.