ARIA and Unicode: Making Decorative Symbols Accessible

WAI-ARIA (Accessible Rich Internet Applications) gives developers a vocabulary for expressing meaning to assistive technologies that HTML alone cannot capture. When it comes to Unicode symbols and emoji, ARIA is your primary tool for drawing a clear line between decoration and communication. Getting this right requires understanding a small set of patterns, knowing when each applies, and being aware of the common mistakes that actually make things worse.

The Core Problem ARIA Solves

HTML communicates structure. A <p> is a paragraph, an <h2> is a second-level heading, a <button> is interactive. But HTML has no native way to say "this star ★ means five-star rating" or "this checkmark ✓ is purely decorative." Screen readers are left to infer meaning from context — or, more commonly, just read the character name from the Unicode database.

ARIA fills this gap with a set of attributes that speak directly to the accessibility tree: the parallel representation of the DOM that assistive technologies consume. The three attributes you will reach for most often when working with Unicode symbols are:

• aria-hidden — removes an element from the accessibility tree entirely
• aria-label — replaces what a screen reader announces with custom text
• role="img" — tells assistive technology to treat an element as an image with a label

Each has a specific purpose. Using the wrong one for the situation creates subtle bugs that are hard to catch without screen reader testing.

aria-hidden: Hiding Decorative Symbols

The most common mistake with Unicode symbols is leaving decorative characters visible to assistive technologies. If a ✦ is there purely to add visual flair to a section break, screen reader users should not have to hear "four pointed star" in the middle of your content.

aria-hidden="true" removes the element and all its descendants from the accessibility tree:

<!-- Before: screen reader announces "bullet" between every item -->
<span>• Item one</span>
<span>• Item two</span>
<span>• Item three</span>

<!-- After: decorative bullets hidden from screen readers -->
<span><span aria-hidden="true">•</span> Item one</span>
<span><span aria-hidden="true">•</span> Item two</span>
<span><span aria-hidden="true">•</span> Item three</span>

A cleaner approach uses CSS-generated content for purely decorative symbols, which is already in a gray zone that some screen readers ignore:

/* Decorative separator — not in the DOM at all */
.section-header::after {
  content: " ✦";
  aria-hidden: true; /* CSS aria-hidden — limited browser support, use sparingly */
}

However, CSS content accessibility is inconsistent across browsers and screen readers. For reliable suppression, put the character in the HTML and apply aria-hidden there.

What aria-hidden Does Not Do

aria-hidden removes elements from the accessibility tree. It does not: - Hide the element visually - Prevent keyboard focus from reaching the element - Apply to the element's parent

That last point catches developers off-guard. If you have a button that contains only a symbol:

<!-- Broken: button is now inaccessible -->
<button>
  <span aria-hidden="true">✕</span>
</button>

The button is now completely empty in the accessibility tree. Screen readers will announce it as "button" with no name — or may announce the filename, URL, or nothing at all. You must always ensure the containing interactive element has an accessible name.

aria-label: Naming Meaningful Symbols

When a symbol carries meaning that you want communicated differently than its Unicode name, aria-label lets you override what the screen reader announces:

<!-- Screen reader announces "check mark" -->
<span>✓</span>

<!-- Screen reader announces "completed" -->
<span aria-label="completed">✓</span>

<!-- Screen reader announces "5 stars" -->
<span aria-label="5 out of 5 stars">★★★★★</span>

aria-label is most appropriate when: - The symbol conveys meaning that the Unicode name does not capture in context ("✓" should say "completed", not "check mark") - Multiple symbols together form a single semantic unit (a star rating) - The symbol's Unicode name is too technical or verbose for the context

Pairing aria-label with aria-hidden

When you have a visual symbol alongside visible text that already describes it, the right pattern is to hide the symbol and let the text speak for itself:

<!-- Redundant: screen reader says "check mark in stock" -->
<span>✓ In stock</span>

<!-- Correct: symbol hidden, text carries the meaning -->
<span><span aria-hidden="true">✓</span> In stock</span>

Do not add aria-label when visible text already communicates the meaning. That creates two announcements — "check mark" from the symbol and "In stock" from the text — or worse, aria-label overrides the text, and you end up with a mismatch between what sighted users see and what screen reader users hear.

aria-label on Non-Interactive Elements

ARIA labels work reliably on interactive elements (<button>, <a>, <input>). On generic elements like <span> and <div>, browser and screen reader support varies. To use aria-label on a generic element, pair it with an appropriate role:

<!-- aria-label on generic span without role — inconsistent support -->
<span aria-label="completed">✓</span>

<!-- Better: give it a role to activate aria-label support -->
<span role="img" aria-label="completed">✓</span>

The role="img" Pattern for Emoji and Icon Symbols

The role="img" pattern is the recommended approach for emoji and symbolic content that functions as an image — conveying a discrete piece of meaning rather than flowing as part of prose.

<!-- Emoji as a standalone image -->
<span role="img" aria-label="success">🎉</span>

<!-- Star rating as an image -->
<div role="img" aria-label="Rating: 4 out of 5 stars">
  <span aria-hidden="true">★★★★☆</span>
</div>

This pattern works because role="img" tells the accessibility tree to treat the element like an <img> — a self-contained graphical unit with a label. The aria-label provides the label. The inner symbols are hidden from the accessibility tree because role="img" on the container creates a boundary: assistive technologies read the container's accessible name and do not descend into children.

Wait — the above is not quite right. role="img" does not automatically hide children. You still need aria-hidden on child elements if you want to suppress their individual announcements:

<!-- Safer: explicitly hide the symbol characters -->
<div role="img" aria-label="Rating: 4 out of 5 stars">
  <span aria-hidden="true">★★★★☆</span>
</div>

Testing with real screen readers is essential here because behavior varies. NVDA with JAWS may treat the children differently than VoiceOver.

When to Use role="img" vs. aria-label Alone

CSS Content Property Accessibility

CSS-generated content via ::before and ::after pseudo-elements has historically been outside the accessibility tree. Modern browsers have changed this — Chromium-based browsers and Firefox now expose CSS content to accessibility APIs, meaning screen readers can announce it.

This creates a situation where you may have decorative CSS symbols that are unexpectedly announced:

/* This arrow may be announced by modern screen readers */
.external-link::after {
  content: " →";
}

The safest approach for decorative CSS content is to use an empty alt via the CSS content property with / "" notation, which is part of the CSS Generated Content spec and has growing browser support:

/* Explicitly mark CSS content as decorative */
.external-link::after {
  content: " →" / "";
}

/* Or provide a label */
.external-link::after {
  content: url(external-icon.svg) / "external link";
}

Until browser support is universal, test any icon-bearing pseudo-element with a screen reader.

For icons rendered via CSS content that should be accessible, the safer approach is to move them to the HTML:

<a href="..." class="external-link">
  Visit site
  <span aria-hidden="true">↗</span>
  <span class="sr-only">(opens in new tab)</span>
</a>

Icon Buttons: The Most Common ARIA Mistake

Icon-only buttons are where ARIA symbol accessibility most frequently breaks down. A close button with only ✕, a search button with only 🔍, a delete button with only 🗑 — these are common patterns and commonly inaccessible.

<!-- Broken: screen reader announces "button" with no name -->
<button class="close-btn">✕</button>

<!-- Option 1: aria-label on the button -->
<button class="close-btn" aria-label="Close dialog">✕</button>

<!-- Option 2: visually hidden text -->
<button class="close-btn">
  <span aria-hidden="true">✕</span>
  <span class="sr-only">Close dialog</span>
</button>

Both options work. aria-label is more concise; the visually hidden text pattern (using a CSS class that positions text off-screen) works in more edge cases and avoids the aria-label support inconsistency on older user agents.

The standard visually hidden utility class:

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

Common Anti-Patterns

Anti-pattern 1: aria-label on the symbol alone, inside a button

<!-- Broken: aria-label on a non-interactive span may be ignored -->
<button>
  <span aria-label="Close">✕</span>
</button>

The aria-label should go on the <button>, not a descendant <span>:

<!-- Correct -->
<button aria-label="Close dialog">
  <span aria-hidden="true">✕</span>
</button>

Anti-pattern 2: Double-announcing visible text and aria-label

<!-- Broken: announces "in stock check mark" or "in stock" twice -->
<span aria-label="In stock">✓ In stock</span>

aria-label on an element replaces its entire accessible name computation, including any text content. So this announces "In stock" from the label — but the visual text "✓ In stock" is still visible on screen, creating a mismatch. Use aria-hidden on the symbol instead:

<!-- Correct -->
<span><span aria-hidden="true">✓</span> In stock</span>

Anti-pattern 3: aria-hidden on a focusable element

<!-- Broken: element is keyboard-focusable but invisible to screen readers -->
<button aria-hidden="true">✕</button>

Never apply aria-hidden="true" to an element that can receive keyboard focus. The element will receive focus but produce no announcement, which is deeply confusing for keyboard users who also use screen readers. Either remove the element from the tab order (with tabindex="-1") or remove aria-hidden.

Anti-pattern 4: Using emoji as status indicators without alternatives

<!-- Broken: status conveyed only by emoji -->
<td>🟢</td>
<td>🔴</td>

Screen reader output: "green circle" and "red circle." That communicates color but not status. Worse, it relies on color to convey meaning, violating WCAG 1.4.1 (Use of Color). Fix it:

<!-- Correct -->
<td>
  <span role="img" aria-label="Online">🟢</span>
</td>
<td>
  <span role="img" aria-label="Offline">🔴</span>
</td>

Testing Strategy

Step 1: Automated scan. Run an automated accessibility checker (axe, Lighthouse, or the browser's built-in inspector). These catch missing alt text, empty button names, and some ARIA misuse. They catch roughly 30–40% of ARIA problems.

Step 2: Check the accessibility tree. In Chrome DevTools, open the Accessibility pane. Navigate to your symbol-containing elements and verify the computed accessible name and role match your expectations. Firefox has an equivalent in the Accessibility tab.

Step 3: Keyboard navigation. Tab through the page without a mouse. Ensure every interactive symbol (button, link, control) receives focus and produces an audible announcement when you activate a screen reader.

Step 4: Screen reader testing. Test with NVDA + Chrome or Firefox on Windows, and VoiceOver + Safari on macOS. These are the two most different environments, so passing both catches the widest range of issues. Check character accessibility with our Character Counter tool to identify what Unicode characters you are working with before testing.

Step 5: Test at multiple verbosity settings. If a symbol only makes sense at one verbosity level, reconsider whether ARIA is doing enough work.

Next in Series: WCAG and Special Characters: Meeting Accessibility Standards — how WCAG 2.2 success criteria specifically apply to Unicode symbols, and what compliance actually requires.