A blind user opens your signup page. She has done this a thousand times before, on a thousand other sites, and her fingers already know the rhythm: tab to the first field, listen, type. She tabs. Her screen reader announces two words. "Edit text."
Nothing else. No "Email address, edit text." No "Full name, edit text." Just an anonymous box with no name, no purpose, no hint of what belongs inside it. The label she can see, the grey placeholder text sitting inside the field, was never a label at all. It was decoration. And decoration is invisible to a screen reader.
She guesses. Maybe she types her email anyway, hoping. Maybe she gives up right there, on field one, before your signup flow has asked her a single real question. Either way, you have lost her, and you will never know it happened, because nothing broke. The page rendered fine. The bug is invisible unless you are listening the way she is.
The Stat: 53.1% of home pages have missing alternative text for images, and unlabeled form fields follow a nearly identical pattern: a control with no accessible name, essentially invisible to a screen reader user trying to interact with it. (Source: WebAIM Million 2026)
The bug hiding in almost every "modern" signup form
This bug is not rare. It is everywhere, and it survives because it looks correct to sighted eyes. A designer wants a clean, minimal form, so instead of a visible label sitting above the field, they put grey instructional text inside the field itself: "Email address," "Full name," "Choose a password." It looks tidy. It looks intentional.
The problem is what happens under the hood. Placeholder text lives in the placeholder attribute of an <input>, and by design, browsers and screen readers do not treat that attribute as the field's accessible name unless nothing else provides one, and even then, support is inconsistent and the text vanishes the moment a user starts typing. A screen reader user who tabs into that field hears only the element's role, "edit text" or "text field," with no indication of what information belongs there.
Compare that to a field with a real <label> element, properly associated with its input using a for attribute that matches the input's id. Now the screen reader announces "Email address, edit text." The user knows immediately what to type, and that information does not disappear once they start typing, because it was never inside the field to begin with. The W3C's own guidance on labeling form controls is unambiguous on this point: every input needs a programmatically associated label, full stop.
The second half of the bug: autofocus goes silent too
The placeholder issue rarely travels alone. Many signup forms also auto-focus the first field on page load, a nice touch for sighted mouse users who land on the page and start typing immediately. But if that autofocus fires before the page has finished announcing itself, or if the field it lands on has no accessible name, a screen reader user gets dropped straight into that anonymous "edit text" with zero context about what page they are even on.
Sighted users glide past this because their eyes fill in everything the code fails to say. Blind users have no such shortcut. They rely entirely on what gets announced, and if the announcement is empty, the experience is empty too. This is the core, uncomfortable truth of accessibility bugs like this one: they cost your business real signups, and they cost you nothing you can see on your own screen. Nobody on your team files a bug report, because nobody on your team hits the bug. The user just leaves.
Think about what that moment feels like from her side. She is not confused about how forms work. She has filled out hundreds of them. What she is missing is the one piece of information every sighted visitor gets for free just by glancing at the screen: what does this box want from me? Without that, she is left guessing whether the field wants an email, a username, a phone number, or nothing at all. Some users will try anyway and hope autocomplete saves them. Many will simply close the tab and go somewhere else, somewhere that told them what to type.
And this is the part that should worry any product team: the visitor who leaves at field one never shows up in your analytics as a "form abandonment." She shows up as nothing. No event fires. No session recording captures a struggle, because there was no struggle to capture, just silence where an announcement should have been. The bug is invisible in your dashboards in exactly the same way it is invisible on your screen.
How to actually fix it, field by field
The fix is not complicated, but it has to be deliberate. Here is the exact pattern to check for on every field in your signup form:
Give every input a real, visible label. Use an actual <label> element with a for attribute pointing to the input's id. Not a <div> styled to look like a label. Not a placeholder. An actual label.
Keep placeholder text as a hint, never as the only name. If you want example text inside the field ("e.g. jane@company.com"), that is fine as a supplement, but it must sit alongside a real label, not replace one.
Test autofocus with a screen reader, not just a stopwatch. If your form auto-focuses a field on load, listen to what actually gets announced. If it is just "edit text," the field needs an accessible name before autofocus is acceptable at all.
Check error states too. A field that gains a red border and a small error message when validation fails needs that error programmatically tied to the input, usually via aria-describedby, or the same invisible-to-screen-readers problem repeats itself the moment something goes wrong. WebAIM's form testing techniques walk through exactly how to verify this with real assistive technology, not just visual inspection.
Run the whole form through a screen reader once, start to finish. This single habit catches more of these bugs than any linter. If you cannot tell what a field wants just by listening with your eyes closed, a blind visitor cannot either.
This one bug, placeholder-as-label plus a silent autofocus, is the single most common reason a signup form fails a screen reader user in the first ten seconds. But it is one item on a much longer list of things that quietly break forms for disabled visitors. If you want the full picture, our complete checklist of the form mistakes developers skip covers the rest, the full list, not just this one bug. And if you want the deeper "why" behind labels, error messaging, and how all of it ties back to conversions you are currently losing, our piece on accessible forms, labels, and conversions is the right next read.
The fix is small, the impact is not
Here is the encouraging part: none of this requires a redesign. It requires a <label> tag, an id/for match, and ten minutes with a screen reader turned on. That is a smaller lift than almost any other item on your product roadmap this quarter, and it is the difference between a blind visitor completing your signup form or bouncing off it at field one, silently, with no error logged anywhere.
If you are not sure whether your own signup form has this bug, or you would rather have a second set of trained ears listen to it than guess, you can get a free audit and find out exactly where the silent breaks are happening.
Want to talk it through with an actual person first? Email experts@wcag.world and someone on our team will walk you through it, or head straight to wcag.world/free-audit to get started.