WCAG and Special Characters: Meeting Accessibility Standards

The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for web accessibility, referenced in legislation across the European Union, the United States, Canada, Australia, and dozens of other jurisdictions. WCAG 2.2 — the current version — is organized into four principles (Perceivable, Operable, Understandable, Robust) and contains specific success criteria that directly govern how you use Unicode symbols, special characters, and emoji on the web.

This is not a gray area. The criteria are precise, testable, and enforceable. Understanding how they apply to symbols will help you build more inclusive products and protect your organization from legal risk.

WCAG Structure: A Quick Orientation

WCAG success criteria are graded at three conformance levels:

• Level A: Minimum requirements. Failures here block access entirely for some users.
• Level AA: The standard that most legal frameworks require. Failures here significantly impair access.
• Level AAA: Enhanced accessibility. Not required globally but valuable for many audiences.

Most organizations target WCAG 2.2 Level AA. The criteria most relevant to special characters span all three levels, but the Level A and AA requirements are the ones you must get right.

WCAG 1.1.1: Text Alternatives (Level A)

Criterion: "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

This is the foundational requirement for all non-text content, and it applies directly to Unicode symbols used as images, icons, or meaningful graphical elements.

What Counts as "Non-Text Content"?

The criterion's definition of non-text content includes images, charts, diagrams, and — crucially — any content that conveys information primarily through appearance rather than text. An emoji used as a status indicator is non-text content. A star rating displayed as ★★★☆☆ is non-text content. An icon button with only a symbol character is non-text content.

Plain Unicode characters in flowing text are generally considered text, not non-text content — the screen reader will announce them via the Unicode character database. But when a symbol is used to replace text (as a button label, status indicator, or visual metaphor), WCAG 1.1.1 applies.

Applying 1.1.1 to Emoji as Images

<!-- Fails 1.1.1: emoji conveys status with no text alternative -->
<td class="status">🟢</td>

<!-- Passes 1.1.1: role=img with aria-label -->
<td class="status">
  <span role="img" aria-label="Active">🟢</span>
</td>

<!-- Also passes: visually hidden text -->
<td class="status">
  🟢 <span class="sr-only">Active</span>
</td>

Applying 1.1.1 to Icon Buttons

An icon-only button — a search icon, a close button, a share symbol — fails 1.1.1 if the button has no accessible name:

<!-- Fails 1.1.1: button has no text alternative -->
<button>🔍</button>

<!-- Passes 1.1.1 -->
<button aria-label="Search">🔍</button>

<!-- Also passes 1.1.1 -->
<button>
  <span aria-hidden="true">🔍</span>
  <span class="sr-only">Search</span>
</button>

Decorative Symbols Are Exempt

WCAG 1.1.1 explicitly exempts "pure decoration" — content that is visual-only and conveys no information. A divider line of ✦✦✦ between sections, a bullet point that is purely stylistic, a sparkle emoji appended to a heading for visual interest: these do not require text alternatives. They do, however, require explicit suppression:

<!-- Decorative: properly hidden -->
<span aria-hidden="true">✦✦✦</span>

The exemption applies only when the symbol truly conveys no information. If removing it would cause any user — sighted or not — to miss information, it is not decorative.

WCAG 1.3.1: Info and Relationships (Level A)

Criterion: "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

This criterion is more subtle than 1.1.1 but just as important. It covers situations where symbols are used to communicate structure or relationships that are not available to assistive technologies.

Symbol-Only Table Headers

<!-- Fails 1.3.1: column meaning conveyed only by symbol -->
<table>
  <thead>
    <tr>
      <th>Product</th>
      <th>✓</th>
      <th>✗</th>
    </tr>
  </thead>
</table>

<!-- Passes 1.3.1: symbol supplemented with text (or aria-label) -->
<table>
  <thead>
    <tr>
      <th>Product</th>
      <th>
        <span aria-hidden="true">✓</span>
        <span class="sr-only">Available</span>
      </th>
      <th>
        <span aria-hidden="true">✗</span>
        <span class="sr-only">Unavailable</span>
      </th>
    </tr>
  </thead>
</table>

Required Field Indicators

The asterisk (*) convention for required fields must be explained. Using * alone as a required field indicator fails 1.3.1 unless the convention is declared:

<!-- Partially fails: the * convention is not explained -->
<label>Email *</label>
<input type="email" required>

<!-- Passes: convention explained, asterisk marked up correctly -->
<p>Fields marked with <span aria-hidden="true">*</span>
<span class="sr-only">an asterisk</span> are required.</p>

<label>
  Email
  <span aria-hidden="true">*</span>
  <span class="sr-only">(required)</span>
</label>
<input type="email" required aria-required="true">

Note that required on the input and aria-required="true" communicate the requirement to assistive technologies directly. The asterisk is visual convention; the ARIA attributes provide the programmatic signal.

WCAG 1.4.1: Use of Color (Level A)

Criterion: "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."

This criterion directly affects emoji and colored symbols used as status indicators. 🔴 and 🟢 use color as the primary differentiator. A user with deuteranopia (red-green color blindness, affecting about 8% of men) may not reliably distinguish them.

The fix is to supplement color with another visual differentiator — shape, text, or pattern:

<!-- Relies on color alone: fails 1.4.1 -->
<span role="img" aria-label="Online">🟢</span>
<span role="img" aria-label="Offline">🔴</span>

<!-- Better: different shapes and text reinforce the distinction -->
<span role="img" aria-label="Online">✅</span>
<span role="img" aria-label="Offline">⛔</span>

<!-- Best: explicit text label alongside the symbol -->
<span><span aria-hidden="true">🟢</span> Online</span>
<span><span aria-hidden="true">🔴</span> Offline</span>

The checkmark in ✅ differs in shape from the circle in ⛔, providing non-color differentiation. The third option is the most robust because it does not rely on symbol recognition at all.

WCAG 1.4.3: Contrast (Level AA)

Criterion: "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (or 3:1 for large text)."

Unicode symbols displayed as text are subject to the same contrast requirements as any other text. A gray checkmark ✓ on a white background may look refined but fail the contrast threshold.

The contrast calculation uses the WCAG relative luminance formula. For practical purposes:

Emoji are rendered by the operating system at the device's emoji font specification and generally cannot have their color overridden with CSS. Because emoji are not text (they are full-color images), WCAG 1.4.3 does not directly apply to them — but 1.4.11 (Non-text Contrast, Level AA) may, and 1.1.1 still requires text alternatives if they convey information.

For symbol characters rendered in CSS with color, run them through a contrast checker. Tools like the WebAIM Contrast Checker or browser DevTools accessibility pane can help.

WCAG 1.4.5: Images of Text (Level AA)

Criterion: "If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text."

This criterion discourages rasterizing text into images. It does not directly address Unicode symbols, but it is relevant when teams are tempted to use an image of a mathematical formula or symbol set instead of actual Unicode characters. Use the actual Unicode characters with proper markup — they are scalable, translatable, copyable, and accessible to a much wider range of assistive technologies than images.

WCAG 2.4.6: Headings and Labels (Level AA)

Criterion: "Headings and labels describe topic or purpose."

When headings or form labels use only symbols, they may fail this criterion. A section titled "★ Featured" may be descriptive enough; a section titled only "★" is not. Apply the same scrutiny to labels: a form field labeled "✉" alone is not descriptive.

Mathematical Notation

Mathematical symbols are a special case. The Unicode Mathematical Operators block (U+2200–U+22FF) and the Mathematical Alphanumeric Symbols block (U+1D400–U+1D7FF) contain characters that are standard in equations. However, screen readers handle mathematical Unicode inconsistently.

The recommended standard for mathematical content on the web is MathML, which provides explicit semantic markup:

<!-- Plain Unicode: screen reader may say "x squared" or garbled output -->
<p>x²</p>

<!-- MathML: screen reader with MathML support says "x squared" correctly -->
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <msup>
    <mi>x</mi>
    <mn>2</mn>
  </msup>
</math>

MathML is now supported natively in all major browsers. For simpler mathematical expressions, an accessible text alternative may be sufficient:

<!-- Superscript with aria-label -->
<abbr title="x squared" aria-label="x squared">x²</abbr>

Check character properties for mathematical symbols with our Character Counter tool to understand what Unicode category and block a given character belongs to before deciding on a markup strategy.

WCAG 3.1.1 and 3.1.2: Language of Page and Parts (Level A / AA)

Criterion 3.1.1: "The default human language of each Web page can be programmatically determined." Criterion 3.1.2: "The human language of each passage or phrase in the content can be programmatically determined."

These criteria affect how TTS engines pronounce text and how screen readers interpret direction and script. If your page primarily uses English but includes Arabic, Chinese, or Korean characters — whether symbols, emoji, or text — the lang attribute must be set appropriately.

<!-- Page-level language -->
<html lang="en">

<!-- Inline language change -->
<p>The Japanese symbol <span lang="ja">円</span> means yen.</p>

<!-- RTL scripts -->
<p>In Arabic: <span lang="ar" dir="rtl">مرحبا</span></p>

A screen reader using an English TTS engine will attempt to pronounce CJK characters phonetically or skip them entirely if lang is not set. Setting lang correctly allows the reader to switch to an appropriate voice or pronunciation database.

WCAG Compliance Checklist for Special Characters

This summary maps common symbol use cases to the criteria they implicate:

A Note on Conformance vs. Usability

Passing WCAG criteria is necessary but not sufficient for full accessibility. A page can meet every success criterion and still be difficult for screen reader users to navigate efficiently. The criteria set a floor, not a ceiling.

The highest-impact practice beyond compliance is to test with actual screen reader users or, at minimum, to use a screen reader yourself for a meaningful amount of time. The difference between "technically compliant" and "genuinely accessible" is usually discovered in user testing, not automated checks.

Next in Series: Accessible Emoji: How to Use Emoji Without Excluding Users — a practical deep dive into emoji verbosity, platform differences, cognitive accessibility, and social media considerations.