Correct Empty Button Labels in WordPress
A button that announces only “button” to a screen reader user has failed at its primary job: it provides an action with no understandable purpose. To correct empty button labels, you need to identify the control’s intended action, expose that action programmatically, and verify that the fix survives theme, plugin, and content updates.
This issue commonly appears in WordPress sites through icon-only controls, search forms, sliders, modal close buttons, page builders, shopping cart interfaces, and custom navigation. It may look minor during a visual review. For visitors using screen readers, speech input, or keyboard navigation, an unlabeled button can make a core task impossible to complete.
Why empty button labels are a WCAG compliance issue
An interactive control needs an accessible name: text that assistive technology can announce and use to identify the control. Empty button labels are generally evaluated under WCAG 2.1 and WCAG 2.2 Success Criterion 4.1.2, Name, Role, Value. A button’s role may be available in the markup, but role alone is not enough. Users also need to know whether it submits a search, opens a menu, removes an item, or closes a dialog.
The impact extends beyond a single technical failure. A visitor may reach a row of icon buttons and hear “button, button, button,” with no context for what each does. A keyboard user may activate an unfamiliar control by mistake. Speech-recognition users may not have a reliable name to speak. These are functional barriers, not cosmetic defects.
For organizations subject to ADA obligations, Section 508 requirements, or internal accessibility policies, unlabeled controls also create avoidable audit findings. They can appear repeatedly across a site when the underlying issue exists in a global header, theme template, or shared form component.
What counts as an empty button label?
A button is effectively unlabeled when its accessible name is missing, empty, or unhelpful. The visible appearance of an icon does not supply a meaningful programmatic name by itself. A magnifying glass may clearly mean search to some visitors, but the button still needs text that assistive technology can interpret.
A common example is an icon-only button with no text alternative:
“`html “`
Because the SVG is hidden from assistive technology and the button contains no text, its accessible name is empty. The appropriate correction depends on the interface, but a direct option is:
“`html “`
For buttons that submit forms, visible text is usually the clearest choice. A form control such as `` should generally contain action text such as “Search,” “Subscribe,” “Send message,” or “Place order.” The label should describe what happens when the user activates the button, not merely identify its visual style.
An image used inside a button can also supply the name when the image has useful alternative text. However, relying on image alternative text is less maintainable than using button text or an explicit accessible name. If the image changes, the button’s purpose can disappear with it.
How to correct empty button labels without creating new issues
Start by determining what the button actually does. “Menu” may be appropriate for a button that opens site navigation. “Close search” is more precise than “Close” when several dialogs or panels could be open. “Remove annual membership” gives better context than a generic “Remove” next to repeated items.
Then select the labeling method that matches the design and code structure.
Prefer visible button text when the interface allows it
Visible text benefits every visitor and is normally the lowest-risk implementation. It is easy to find during testing, does not depend on ARIA support, and makes intent clear for users with cognitive or low-vision needs. If a button can reasonably display “Download report” instead of a download icon alone, that is often the better design decision.
When a compact interface requires an icon-only button, provide a programmatic label. An `aria-label` works well when no visible text exists. For example, a close icon can use `aria-label=”Close dialog”`, while a cart icon can use `aria-label=”View shopping cart”`.
Use visually hidden text when it supports the component
Some teams prefer hidden text inside the button instead of `aria-label`. This allows the label to remain in the document structure and can simplify localization workflows:
“`html “`
The hidden-text class must visually conceal the text without removing it from the accessibility tree. Do not use `display: none`, `visibility: hidden`, or the HTML `hidden` attribute for label text that needs to be announced.
There is no universal rule that hidden text is always better than `aria-label`. It depends on the component, the development standard, translation process, and how the theme or plugin renders the control. The requirement is consistent: the final accessible name must be meaningful and available to assistive technology.
Keep the accessible name aligned with visible text
If a button has visible text, its accessible name should generally include that same text. This matters for WCAG Success Criterion 2.5.3, Label in Name, particularly for speech-input users who may try to activate a control by the words they see.
For example, a visible “Save changes” button should not carry an accessible name of only “Submit.” “Save changes” is the clearer accessible name as well. Avoid replacing useful visible text with an unrelated `aria-label`, because ARIA can override the text that screen readers announce.
Label state changes accurately
Buttons that expand, collapse, mute, favorite, or toggle settings need labels and states that work together. A navigation control can be labeled “Main menu” while `aria-expanded=”false”` communicates that it is closed. When activated, the state should update to `aria-expanded=”true”`.
For a control whose action changes, update the label when appropriate. A button that starts as “Show filters” may need to become “Hide filters” after activation. Do not leave users with a label that describes the previous action.
Where WordPress sites commonly introduce the problem
The source is often outside the page editor. Theme headers frequently contain unlabeled mobile-menu, search, account, and close buttons. WooCommerce extensions can introduce icon-only cart, quantity, wishlist, and remove-item controls. Form plugins, page builders, event calendars, slider plugins, and popup tools may also generate buttons dynamically.
Custom blocks deserve special attention. A block may look correct in the WordPress editor but output an empty `
Also review reusable areas: navigation menus, widget regions, template parts, modal dialogs, login flows, document viewers, and cookie preference panels. One defective site-wide component can affect every page and significantly increase the number of accessibility errors in an audit.
Validate the fix in the rendered interface
Code inspection is useful, but it is not sufficient. After correcting an empty label, test the rendered page in the browser. Confirm that the control receives keyboard focus, that its name describes the action, and that activating it produces the expected result.
Automated scanning is an efficient way to find recurring unlabeled button patterns across templates and published content. WP ADA Compliance Check can help WordPress teams identify empty button labels alongside other WCAG and Section 508 issues, with reports that point to the affected code or content location. Automated results should be followed by focused manual verification, especially for dynamic controls and changing states.
Do not treat a generic label as a completed remediation. “Click here,” “Button,” “Icon,” and file names such as “search.svg” may technically add text, but they do not provide a useful purpose. The standard is not simply whether a screen reader announces something. It is whether the visitor can understand and operate the control.
A properly named button is a small implementation detail with a large operational effect. When every action communicates its purpose, visitors can navigate forms, menus, purchases, and account tasks with confidence – and your WordPress publishing process moves closer to accessibility that holds up in real use.
Subscribe
Subscribe to receive daily Web Accessibility - Did you know? articles in your inbox.
