Form Labels in WordPress: Why label Beats placeholder Every Time

An <input>, <select> or <textarea> without a linked <label> is a riddle. A screen reader announces "edit text" or "combo box" with no clue what the field is for. Browser autofill cannot suggest the right value either.

Why this matters

This is an explicit international accessibility guidelines Level A requirement, 3.3.2 Labels or Instructions. A blind user filling out a contact form with NVDA or VoiceOver hears: "First name, edit text" - and knows what to type. Without a label they hear "edit text" and stop. With five fields they hear "edit text" five times with no idea which is which. placeholder looks like a label to sighted users, but as soon as they start typing it disappears - leaving them without a reminder of what was asked.

Beyond accessibility, proper labels enable browser autofill. <label for="email">Email</label><input id="email" type="email" autocomplete="email"> lets Chrome suggest the saved address. Without the link, autofill either fails or suggests the wrong value. UX-wise, clicking a label focuses the input - faster on mobile.

How to detect

Run WAVE or axe DevTools on form pages - they flag "missing form label". Manually: view source, look for <input without an id or without a paired <label for="...">. RankPlus walks form-page DOMs and checks for the linkage.

How to fix

1. For every existing field, ensure a unique id and a <label> linked via for:

   <label for="contact-email">Email address</label>
   <input id="contact-email" type="email" name="email" required>

2. Alternative: <label>Email <input type="email"></label> - also valid, less flexible.
3. If you must hide the label visually (a search input in a navbar, for example), use accessible-hide CSS - never display:none:

   .visually-hidden {
       position: absolute;
       width: 1px; height: 1px;
       padding: 0; margin: -1px;
       overflow: hidden;
       clip: rect(0, 0, 0, 0);
       border: 0;
   }

   And in HTML: <label for="search" class="visually-hidden">Search</label>.
4. An alternative to a hidden label: aria-label="Search" directly on the input. Acceptable, but a real label is preferable.
5. In a form plugin (Contact Form 7, Gravity Forms, Forminator, WPForms): check the "Show Labels" / "Display Field Labels" setting - sometimes disabled for design reasons. Re-enable.
6. Add appropriate autocomplete tokens: email, tel, name, street-address. Documented on MDN, they help both UX and automation.
7. Test with NVDA/VoiceOver: tabbing into a field should speak "First name, edit text" instead of just "edit text".

Common mistakes

• placeholder instead of label: "Type your name here" disappears as soon as the user starts typing. Keep a label.
• label without for: <label>Email</label><input> - not linked, not accessible.
• Two fields with the same id: invalid HTML, only the first input is linked. Use unique IDs like contact-email.
• display:none on labels: screen readers also skip them. Use visually-hidden.
• Unclear required indication: "required" should be in the label or via aria-required. A red asterisk alone is not enough.

Verifying the fix

Open NVDA/VoiceOver, tab through the form. Each field should announce its description: "First name, edit text, required." Run axe DevTools - Forms category should pass. RankPlus turns green.