Placeholder Text and Accessibility: WCAG, Contrast and Screen Readers

There is one distinction that resolves most accessibility questions about placeholder text, and almost every guide skips it: the difference between placeholder text in the content layer and placeholder text in the accessibility layer.

Latin in a paragraph is harmless. Everyone sees the same meaningless block, and nobody is worse off than anyone else. Latin in an alt attribute, an aria-label, or a form label is a different category of problem entirely — it degrades the experience for one group of users specifically, and it is invisible to everyone else on the team.

That invisibility is what makes it dangerous. A sighted reviewer looking at a mockup cannot see that aria-label="Lorem ipsum" is there. It passes design review, passes QA, and ships.

What screen readers actually do with Latin

It's worth knowing the real behaviour, because it's worse than "reads out nonsense."

Screen readers apply pronunciation rules for the page's declared language. With lang="en", an English synthesiser attempts English pronunciation of Latin words. "Consectetur" and "adipiscing" come out as garbled approximations. Some strings trigger character-by-character spelling when the synthesiser can't resolve them, which is dramatically slower.

More importantly, screen reader users navigate structurally — jumping by heading, by landmark, by link, pulling up a list of every link on the page. Those navigation modes depend entirely on text content. A heading list reading "Lorem ipsum dolor / Lorem ipsum dolor / Lorem ipsum dolor" conveys nothing about the page. A link list of identical Latin fragments makes the page unnavigable.

So placeholder text in structural elements doesn't just add noise — it removes the primary means of navigation.

The placeholder attribute is not a label

Two different things share the word "placeholder," and conflating them causes real harm.

The HTML placeholder attribute puts hint text inside an input. It is not a label, and using it as one fails users in several ways at once:

<!-- Broken: no label at all -->
<input type="email" placeholder="Email address">

<!-- Correct -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com">

The problems with the first version compound. The hint disappears as soon as the user types, so anyone who loses their place has no way to recover what the field wanted. That hits users with memory and attention difficulties hardest. Placeholder text is styled lighter than real text, often too light to read. Assistive technology doesn't treat it as a dependable name for the field. And voice control users say "click Email address" expecting a label to target.

The rule: every input gets a real, visible, persistently rendered label. placeholder is for supplementary format hints only — you@example.com, DD/MM/YYYY — never for the field's identity.

Which WCAG criteria this actually touches

The Web Content Accessibility Guidelines are the standard most accessibility law points to, usually at level AA. Placeholder misuse runs into four criteria:

On the legal side the pattern is consistent. In the US, the ADA is routinely applied to websites and Section 508 covers federal ones. The European Accessibility Act has applied to many consumer-facing digital products and services since June 2025. The UK and Canada have their own public-sector rules. Nearly all of them reference WCAG AA directly or through a harmonised standard. A placeholder-only form fails at level A, below the bar every one of them sets.

Contrast: the browser is fine, your CSS probably isn't

The common advice says browser-default placeholder colours fail contrast. We checked, and in current Chrome that's no longer true. In Chrome 153, an unstyled input's placeholder computes to #757575, which is 4.61:1 on white: a pass at AA, just.

The failures come from the styling layered on top. Some real values, measured on white:

The Tailwind rows matter because v4 sets that default in its base styles: color-mix(in oklab, currentcolor 50%, transparent). Any v4 project that doesn't override it ships placeholders below AA, and nothing in the build will warn you. If you use it, set the colour explicitly:

::placeholder {
  color: #595959; /* 7.0:1 on white */
  opacity: 1;     /* Firefox has historically lowered placeholder opacity */
}

Check the dark theme separately. The same grey won't work on a dark background, so measure the actual pair rather than assuming.

Never let placeholder text into these

Treat this as a hard list. Everything here is content some users depend on:

<!-- All of these are failures -->
<img src="product.jpg" alt="Lorem ipsum dolor sit amet">
<button aria-label="Lorem ipsum"><TrashIcon /></button>
<a href="/pricing">Lorem ipsum</a>
<nav aria-label="Lorem ipsum">
<h2>Lorem ipsum dolor</h2>
<title>Lorem ipsum — Site</title>
<input aria-describedby="hint"><span id="hint">Lorem ipsum</span>

Alt text, ARIA labels and descriptions, link text, headings, page titles, form labels, error messages, button text, and landmark labels. If a screen reader announces it as a distinct thing, it must be real.

For images you haven't sourced yet, make the gap explicit rather than filling it with Latin:

<img src="placeholder.jpg" alt="[TODO: describe the product in use]">

That is still wrong to ship, but it announces itself as unfinished in a way alt="Lorem ipsum" does not — and it's greppable.

Note the separate case of genuinely decorative images, which take an empty alt, not a missing one:

<img src="divider.svg" alt="">

alt="" tells assistive technology to skip the image. Omitting alt entirely makes some screen readers announce the filename, which is worse than either.

Link text deserves particular attention

Screen reader users routinely pull up a list of every link on a page, stripped of surrounding context. Placeholder link text makes that list useless — the same failure mode as a page full of "click here," but harder to spot because it looks like unfinished work rather than bad writing.

If real link text doesn't exist yet, describe the destination:

<a href="/pricing">[Link: pricing page]</a>

The destination is almost always known even when the copy isn't. Write that down instead of deferring it.

Placeholder text does not excuse broken structure

A useful property: most accessibility fundamentals are content-independent, so you can and should get them right while the copy is still Latin.

Heading hierarchy is about nesting, not wording. An h1 followed by an h3 is a defect whether the text is real or placeholder, and it's fully testable now.

Landmarks — main, nav, header, footer, aside — depend on markup, not content.

Focus order follows DOM order. Placeholder text has no bearing on whether tabbing moves sensibly through the page.

Keyboard operability — every interactive element reachable and actionable by keyboard, with a visible focus indicator — is entirely independent of copy.

Contrast is a colour property. Latin at 3:1 fails exactly as real text at 3:1 does.

So the excuse "we'll fix accessibility when the real content arrives" is mostly wrong. The majority of issues are present and fixable in the placeholder stage, and fixing them then is far cheaper.

Placeholder text invalidates accessibility testing

The corollary: any test where a participant must understand the content is worthless with placeholder text.

You cannot assess whether a screen reader user can complete a checkout when the buttons say "Lorem ipsum." You are measuring their tolerance for nonsense, not your interface. The same applies to cognitive walkthroughs, comprehension testing, and any usability session involving assistive technology.

Automated tools are a partial exception — axe, Lighthouse, and similar will still flag missing labels, contrast failures, and hierarchy problems on a placeholder page. Run them early. But an automated pass on a Latin page is not an accessibility audit; it's a check that the structural scaffolding is sound.

For anyone with cognitive disabilities, there's an additional consideration during review: placeholder text can be genuinely difficult to distinguish from real content. Someone asked to evaluate a mockup may not know which parts are provisional. Label it explicitly rather than assuming it's obvious.

Making it visible so it can't ship

Since the dangerous cases are invisible in visual review, catch them mechanically.

Lint the accessibility layer. A rule that flags placeholder patterns in alt, aria-label, aria-description, title, and placeholder attributes catches the whole class before commit.

Grep in CI, scoped to exclude legitimate uses:

git grep -niE "lorem ipsum|dolor sit amet" -- \
  'src/**' ':!src/**/*.test.*' ':!src/**/*.stories.*' ':!src/fixtures/**'

Use a distinctive marker. Bracketed placeholders like [TODO: alt text] are trivially greppable and obviously unfinished. Latin blends in.

Run a screen reader yourself. VoiceOver on macOS is Cmd+F5; NVDA on Windows is free. Ten minutes tabbing through your own page with the screen off will teach you more about where placeholder text is doing damage than any checklist. This is the single highest-value habit on this page.

A workable convention

For teams that need placeholder content in shared mockups, a consistent bracket convention works well:

[H1: Product name and primary benefit — 50-70 chars]
[Body: 2-3 sentences on the core problem this solves]
[CTA button: action verb + object, e.g. "Start free trial"]
[Image alt: person using the product in a workspace]

This does three jobs at once. It's readable by anyone, including screen reader users reviewing the mockup. It communicates the intended length and purpose to whoever writes the copy. And it's obviously unfinished, so it can't quietly ship. Latin does none of these.

Conclusion

Placeholder text in body copy is a non-issue for accessibility. Placeholder text in the accessibility layer — alt, ARIA, labels, headings, link text, titles — is a defect that harms a specific group of users and is invisible to everyone else on the team.

Keep the two separated and most of the risk disappears. Get the content-independent fundamentals right while the copy is still Latin, since heading structure, landmarks, focus order, keyboard operability, and contrast are all testable now. Then replace everything meaning-dependent before any test involving real people.

And spend ten minutes with a screen reader on your own work. It reframes what "placeholder" means faster than reading about it will.