Skip to main content

WCAG 2.5.3 — Label in Name: Visible Label Not in Accessible Name

seriousWCAG 2.5.3 · Level Acms scope

Form fields and buttons on your website show one label text visually but use different text for screen readers. This confuses voice control users who can't activate elements by saying what they see. Under the ADA Title II rule, visible labels must match the accessible names announced by assistive technology.

Who Is Affected

Voice control users (including people with mobility impairments), screen reader users, and anyone using speech recognition software to navigate your site. This particularly impacts users with conditions like ALS, multiple sclerosis, or repetitive strain injuries who rely on voice commands.

What This Means

When a form field or button displays visible text like "First Name" but its accessible name (what screen readers announce) is "fname" or something different, assistive technology users get confused. Voice control users will say "click First Name" but the software can't find that text in the accessible name, so the command fails.

The accessible name is built from several sources: aria-label attributes, aria-labelledby references, placeholder text, and the visible label text. WCAG 2.5.3 requires that the visible label text be included somewhere within the accessible name, preferably at the beginning.

Common failures include buttons with generic accessible names like "Click here" when the visible text says "Apply for Permit," or form fields where the visible label doesn't match the programmatic label.

Fix: CMS / Theme

Review your form templates, button components, and any custom form widgets for label mismatches:

  1. Audit form templates: Check if your theme's contact forms, search boxes, or other form components have mismatched labels.
  2. Review button templates: Ensure buttons like "Submit," "Search," and "Download" have accessible names that include their visible text.

In Joomla:

  • Go to Extensions → Modules and check any custom form modules
  • Review Components → Contact → Categories for contact form labels
  • Check your template's mod_search and mod_login overrides in /templates/yourtheme/html/

In WordPress:

  • Review active form plugins (Contact Form 7, Gravity Forms, etc.) for label configuration
  • Check Appearance → Widgets for any search or contact form widgets
  • Examine your theme's searchform.php and any custom form templates
  1. Fix the code: Ensure visible label text appears in the accessible name. For buttons, the visible text should match the aria-label or be included in aria-labelledby content.

Fix: Content Editor

For individual pages with form elements or custom buttons:

  1. Identify the problem: Look for form fields or buttons where the visible text doesn't match what a screen reader would announce.

  2. Fix form fields:

    • Ensure the visible <label> text matches any aria-label attributes
    • If using placeholder text as labels, add proper <label> elements that include the placeholder text
    • Remove generic aria-label values like "input field" in favor of descriptive labels
  3. Fix buttons:

    • Change generic button text like "Click here" to match the action: "Download Tax Form"
    • If the button contains an icon with separate aria-label, ensure the aria-label includes any visible text
    • For buttons with both visible text and images, include the visible text in the accessible name
  4. Test your changes: Use a screen reader or browser inspection tools to verify the accessible name includes the visible label text.

Standard Reference

WCAG 2.1 Success Criterion 2.5.3 — Label in Name, Level A

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Check if your government website has this issue

OctoComply scans your website and documents for WCAG 2.1 AA violations. The free tier covers up to 10 pages.

Run a Free Scan