F71: When 'c' Isn't 'c' and Screen Readers Know It

Text look-alikes are a quiet accessibility failure. Characters that appear identical to human eyes are processed as completely different symbols by assistive technology — and WCAG Failure F71 (opens in new window) documents exactly why this breaks equal access.

The Unicode standard contains over 140,000 characters spanning dozens of writing systems. Some of those characters share glyphs — they look the same on screen. Developers and content creators sometimes exploit this intentionally (for stylized text effects) or stumble into it accidentally. Either way, the result is the same: a screen reader encounters a character it cannot interpret as intended, and a user gets meaningless output.

The Failure

F71 describes a specific pattern: using characters from one script that visually resemble characters from another, without providing a text alternative. The WCAG 2.2 failure document (opens in new window) offers a precise example. The word that looks like "cook" is actually assembled from four different Unicode code points:

U+03F2  ϲ  (Greek Small Letter Lunate Sigma)
U+043E  о  (Cyrillic Small Letter O)
U+03BF  ο  (Greek Small Letter Omicron)
U+006B  k  (Latin Small Letter K)

Only the final character — the k — is from the Western Latin alphabet. Visually, the word renders as ϲоοk. To a sighted reader with standard font rendering, it reads as "cook." To a screen reader, it may be announced as "Greek small letter lunate sigma, Cyrillic small letter o, Greek small letter omicron, k" — or some variation depending on the tool and language settings. The same failure applies when these characters are implemented via HTML character entities:

<!-- This looks like "cook" but is not processed as "cook" -->
&#x03F2;&#x043E;&#x03BF;&#x006B;

The failure is not the encoding mechanism. It's the character choice itself. Whether you use the raw Unicode character or its entity reference, a Greek sigma is still a Greek sigma.

This failure maps directly to Success Criterion 1.1.1 Non-text Content (opens in new window). The standard requires that non-text content — including content that functions as text but isn't processable as such — carries a text alternative. F71 applies to any technology, not just HTML.

Why This Matters

The gap between visual rendering and semantic meaning is exactly where disabled users get left behind.

For screen reader users, the impact is immediate and disorienting. A word that looks like "cook" being announced as a string of Greek and Cyrillic character names provides no usable information. If that word appears in a navigation label, a button, a heading, or a product name, the user cannot understand or act on it. This isn't a minor inconvenience — it's a complete information barrier.

Users who rely on refreshable Braille displays face the same problem from a different angle. The Braille output will reflect the actual Unicode characters, not the intended Latin text. A Greek sigma produces a different Braille cell than a Latin "c." The word becomes unreadable in a different modality.

Users with cognitive disabilities who rely on text-to-speech for reading support are equally affected. The technology reads what's there — not what it looks like.

This failure pattern also surfaces in ways that aren't immediately obvious. Decorative "ASCII art" text, stylized social media posts using mathematical alphanumeric symbols (like 𝓈𝓉𝓎𝓁𝒾𝓈𝒽 text generated by Unicode math block characters), and logo text rendered through character substitution all carry this same risk. The disability community has documented this extensively — particularly around social media content, where Unicode font generators are widely used to create visual effects that completely break screen reader access.

The Fix

The corrected approach has two paths, depending on context.

Path 1: Use actual Latin characters. If the goal is to display the word "cook," use the actual characters:

<!-- Correct: actual Latin characters -->
cook

This is always the preferred solution when the look-alike characters are being used purely for visual effect.

Path 2: Provide a text alternative when the visual form must be preserved. If the stylized character string serves a specific visual purpose that cannot be achieved with standard characters, wrap it with an accessible text alternative:

<!-- Using aria-label to provide the intended text -->
<span aria-label="cook">ϲоοk</span>
<!-- Or hide the visual form from assistive technology and provide real text -->
<span aria-hidden="true">ϲоοk</span>
<span class="visually-hidden">cook</span>

The visually-hidden CSS class should position the text off-screen without display: none or visibility: hidden, which would hide it from screen readers as well:

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

The ARIA Authoring Practices Guide (opens in new window) provides additional patterns for managing accessible names when visual and semantic content diverge.

Applying This

Automated testing tools will not catch F71 reliably. A tool scanning for SC 1.1.1 (opens in new window) compliance looks for images without alt attributes, not for Unicode characters that happen to resemble Latin letters. This is precisely the kind of nuanced failure that our research on automated vs. manual testing identifies as falling outside automated detection — and it reinforces why a hybrid methodology matters.

For development teams, the practical catches are:

• Code review: Flag any non-Latin characters appearing in content that's intended to be read as standard English (or whatever the page language is). A linter rule checking for non-ASCII characters in text nodes can surface candidates for review.
• Content audits: Decorative text effects, logo treatments, and marketing copy are high-risk areas. Anyone using a "fancy text generator" to style content is almost certainly producing F71 failures.
• Screen reader testing: Run content through NVDA or JAWS with character verbosity settings enabled. Look-alike failures become immediately audible.
• Social media content: If your organization repurposes social content for web use, audit that content specifically. Unicode font styling is common on social platforms and routinely imports F71 failures into web content.

The fix is almost always simple once the failure is identified. The challenge is detection — and that requires human reviewers who know what to look for. As our analysis of compliance methodology makes clear, failures that require semantic understanding of content intent sit firmly in the manual audit column.

CORS Perspective

From a community lens, F71 is a failure that disproportionately affects screen reader users in environments where visual creativity is prioritized over access — marketing, social media, branded content. The gap between what sighted users experience and what assistive technology delivers reflects a broader pattern: design decisions made without disabled users at the table. Operationally, this is a low-cost fix with high community impact — it belongs on any team's "chop list" of quick wins. The risk is real but often invisible to automated scanning, which means organizations relying solely on automated compliance tools, as our research on standards fragmentation documents, will systematically miss it. Strategically, catching F71 is an argument for investing in manual review capacity alongside automated tooling — not as a compliance checkbox, but as a commitment to content that actually works for everyone who needs it.