Updated:

Making emojis and icons screen reader accessible

by Elle Smith

While emojis and icons often look like images to visual users, they often aren’t real images in the code. This means there are specific strategies and considerations for making emojis and icons accessible to assistive technology users. 

In this article, we’re focusing on ways you can make sure your emojis and icons are accessible with screen readers.

What is an emoji?

An emoji is a picture character. Not to be confused with an emoticon : ) Emoticons are expressions built out of characters like parentheses and colons, whereas emojis are like little pictures used to substitute words, reinforce emphasis, and set the tone of text based messages. 

Think of these three messages and how the emoji shifts the meaning. 

  1. “I’m heading home.”
  2. “I’m heading home 🥳”
  3. “I’m heading home… 💀”

The first example leaves no clue as to how the person is feeling, whereas the second and third give tone cues of excitement and exhaustion. 

What is an icon? 

An icon is a symbol that represents an object or action. For many users, icons provide easy-to-follow visual cues. For example, someone doesn’t have to hunt for the “print” setting when there is a little printer icon to guide them. 

Print icon

Importantly, icons are often not true images, but rather SVGs or sometimes they can come from font libraries. This means there are some accessibility methods that you have to use other than the traditional alt text method you would use for images.

Why emojis and icons need to be accessible 

Emojis and icons add a visual layer to communication. While these visual elements enhance communication for some, for those with visual or cognitive disabilities, these symbols can easily create gaps and confusion in communication. 

Emojis

While emojis feel like tiny images, they are actually “picture characters” with predefined names. Because they are code rather than images, they carry a literal definition that often conflicts with our human intent. 

Disconnect from intention

The primary problem is that a screen reader reads the official name of the character, not the vibe you intended. When your message relies on an emoji to provide the punchline or tone, you run the risk of your audience missing the point entirely. 

Here are a few common examples where the standard name of the emoji clashes with the intended “vibe.” 

  • The “Thank You” 🙏: Often used to represent “thank you” or “please,” but it is announced as “Hands pressed together.” 
  • The “Toxic Trait” 🚩: In the popular “Red Flag” trend, a statement like “I don’t like coffee 🚩” relies on the flag to signal a warning. However, a screen reader announces “Triangulage flag on post.” Without the visual context, it just sounds like a random fact about coffee. 
  • The “Fist Bump” 👊: Intended as a sign of solidarity or a greeting, but it is announced literally as “Closed fist.” 

Cognitive load

While sometimes emojis can assist those with cognitive and learning disabilities by breaking up text, excessive use can increase cognitive friction. Long strings of emojis can increase the processing load of those with cognitive disabilities. Additionally, long strings of emojis also increase cognitive load for those using a screen reader as they have to listen to repeated descriptions of “fire, fire, fire, fire, fire, fire” to understand that a product is indeed “fire.” 

Icons

Icons are meant to be a universal language, but they are often surprisingly ambiguous. When we rely on a symbol without a text label, we create two distinct problems: one for the code and one for the human. 

The invisible button problem

A common hurdle is the “icon-only” button. If a button contains a gear icon but no text, it often means that there is nothing for a screen-reader to read; thus creating an “invisible” button.

To a screen reader, this isn’t a “settings” link, it’s just announces as “Button.” Without a label, the user is forced to click and hope for the best, turning your navigation into a guessing game. 

The contextual clash

The meaning of a symbol changes based on where it sits. This isn’t just an accessibility issue; it’s a universal design flaw. 

Take the “Heart” Icon ♥️. Depending on the website, that heart could mean:

  • “Like” a post (Social media)
  • “Save to wishlist” (E-commerce)
  • “Medical History” (Healthcare)

If a sighted user has to pause to wonder, “Wait, am I liking this or buying it…”, there is a communication issue. For a screen reader user, this clash is even more dangerous. If the accessible name is simply “heart,” they have no way of knowing the consequence of their click. 

Never assume the icon speaks for itself. Whether you use a visible text label or a hidden accessible name (we’ll go over these later in this post), you must define the action (e.g. “Add to Favorites”), not just describe the shape (“Heart”). 

How to include text alternatives for emojis and icons

When designing your website, there are three primary ways to make emojis and icons more accessible. 

  1. The visible text method

One solution is to add a visible text label next to your emoji or icon. This method reduces cognitive load for many people, not just screen reader users. 

  • How it works: You place the text directly next to the symbol and hide the symbol from the screen reader. 
  • The code (Icon):
<button> ><i aria-hidden="true" class="fa-gear fa-solid"></i> Settings </button>
  • The code (Emoji): 
<a href="/favorites">

  <span aria-hidden="true">❤️</span> My Favorites

</a>
  • Why it wins: It eliminates the “invisible button” problem because when a screen reader user encoungers the button, the icon is hidden and the text is announced instead. 
  1. The screen reader only method

To use less ARIA, you can use hidden text to add context to your icon or emojis. 

  • How it works: You hide the visual element and provide a screen reader only span that is hidden from sighted users via CSS. 
  • The code:
<span aria-hidden="true">🚩</span> <span class="sr-only">Red flag behavior:</span>
  • Why it wins: It allows you to replace the literal description like “triangular flag on post” with the actual intent. 
  1. The aria-label method

If your design absolutely requires an “icon-only” button, you can provide an invisible name accessible to screen readers, also known as an ARIA-label. ARIA-labels should be five words or less to reduce long announcements for screen reader users. 

  • The rule: If you are putting an aria-label on a <span>, <i>, or <div>, you must include role=”img”. Without that role, many screen readers will treat the ARIA-label as “invalid” and ignore it. 
  • The code (Icon):
<button aria-label="Search"><svg aria-hidden="true">...</svg></button>
  • The code (Emoji): 
<span role="img" aria-label="Feeling energized">⚡</span>
  • Key tip: Notice that in the icon example, we label the button and hide the icon. This prevents the screen reader from saying “search, image, button” and keeps it to “search, button.” 

Emojis and social media

Since you can’t edit the HTML in your email clients or social media spaces, your accessibility becomes about content strategy rather than code strategy. 

Consider the following best practices when it comes to emojis and icons in these closed systems:

  • Placement: Keep emojis at the end of sentences so they don’t interrupt the flow of the screen reader.
    • Bad: “I can’t wait for the ⛱️ beach this weekend!”
      • Screen reader might say: “I can’t wait for the *umbrella stuck in the sand* beach this weekend”
    • Good: “I can’t wait for the beach this week! ⛱️”
      • Screen reader might say: “I can’t wait for the beach this weekend! Umbrella struck in the sand.” 
  • Context: If an emoji provides vital meaning (like a warning), write that meaning into the text.
    • Bad: “I don’t like coffee 🚩”
      • Screen reader might say: “I don’t like coffee triangular flag on post.” (The warning is lost.) 
    • Good: “Red flag: I don’t like coffee 🚩”
      • Screen reader might say: “Red flag: I don’t like coffee triangular flag on post.” 
  • Limit: Don’t stuff your posts full of emojis because screen readers will read the name of every single one of them.
    • Bad: “So excited for this launch! 🥳🚀✨🔥🙌
      • Screen reader might say: “So excited for the launch! Party face with a party horn hat and confetti rocket sparkles fire hands raised in celebration.”
    • Good: “So excited for the launch! 🚀”
      • Screen reader might say: “So excited for the launch! Rocket.” 

Key takeaways

Before we leave you to coding your emojis and icons, let’s go over some of the basics we learned in this article:

  1. Emojis are code, not images: Remember that emojis are not images. Screen readers announce a predetermined name. 
  2. The predetermined name ≠ equal intent: The official name of the emoji (e.g. “hands pressed together”) often differs from the user’s intent (“Thank you”). 
  3. Give context: The same icon or emoji can mean different things in different contexts Always write text alternatives based on the symbols specific purpose at that moment. 
  4. The three methods of accessible emojis/icons: Try to provide either text near the icon or emoji, hidden text, or an accessible name via aria-label for icons and emojis. 
  5. Hiding emojis and icons: Hide emojis and icons from screen reader users using aria-hidden=”true” when the icon or emoji is either purely decorative or redundant to the nearby text. 

You’re ready to make the web a little more expressive (and accessible)! 🎉