SymbolFYI

WCAG 1.1.1: Text Alternatives for Symbols

WCAG Success Criterion 1.1.1 (Non-text Content) is a Level A requirement—the baseline level of accessibility conformance—that mandates text alternatives for all non-text content. This criterion directly applies to symbols, icons, emoji, mathematical notation, and decorative glyphs used in web content.

The Core Requirement

The full criterion states: "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose." This means every symbol that conveys meaning must have an associated text string that communicates the same information to users who cannot perceive the symbol visually.

Applying the Criterion to Symbols

Informative Symbols

Symbols that convey information must have text alternatives. A checkmark indicating task completion, a warning triangle indicating an error, or a star rating indicating quality all fall into this category:

<!-- Informative: requires text alternative -->
<span role="img" aria-label="Task complete">✓</span>
<span role="img" aria-label="Warning: required field">⚠</span>
<span role="img" aria-label="4 out of 5 stars">★★★★☆</span>

Decorative Symbols

Symbols used purely for visual decoration—separators, flourishes, bullet point ornaments—should be hidden from assistive technologies. WCAG explicitly exempts decorative non-text content from the text alternative requirement:

<!-- Decorative: hidden from assistive tech -->
<span aria-hidden="true">✦</span>
<span aria-hidden="true">—</span>

Symbols Used as Controls

When a symbol serves as an interactive control (a button, link, or form element), the text alternative must describe the control's function, not just the symbol's appearance:

<!-- Describes function, not appearance -->
<button aria-label="Delete item">
  <span aria-hidden="true">🗑</span>
</button>

<!-- Incorrect: describes appearance only -->
<button aria-label="Trash can icon">🗑</button>

Mathematical Notation

Mathematical symbols and equations are a particular challenge. WCAG 1.1.1 applies to math content, and the recommended solution is MathML with appropriate annotations:

<math aria-label="x squared plus y squared equals z squared">
  <msup><mi>x</mi><mn>2</mn></msup>
  <mo>+</mo>
  <msup><mi>y</mi><mn>2</mn></msup>
  <mo>=</mo>
  <msup><mi>z</mi><mn>2</mn></msup>
</math>

For Unicode approximations of math (e.g., using superscript characters), include an accessible label on the containing element.

Failure Conditions

Common failures of SC 1.1.1 related to symbols include:

Using a Unicode arrow (→) as a link with no text alternative
Displaying a checkmark (✓) or cross (✗) as the sole indicator of status
Using emoji in headings or navigation without aria-label
Inserting symbols via CSS content property without providing accessible text in the HTML

CSS-Inserted Symbols

Symbols inserted via the CSS content property are not in the DOM and are handled inconsistently by screen readers. The safest approach is to keep meaningful symbols in HTML and use aria-hidden and aria-label as appropriate. If CSS-inserted symbols must convey information, provide hidden text in the HTML:

.required::before {
  content: "*";
  aria-hidden: true; /* CSS aria-hidden has no effect; use HTML */
}

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

Automated Testing Limitations

Automated accessibility checkers can identify symbols that lack any accessible name on interactive elements, but they cannot determine whether a text alternative is meaningful or accurate. Manual review with a screen reader is necessary to verify that symbol alternatives communicate the correct information in context.

WCAG Text Alternatives