UX Writers Collective has moved! You’ve just been redirected to our new site, UX Content Collective at uxcontent.com. We’re so glad you’re here! Read more about the update.

Accessible content design for emojis

Emojis have changed the way we convey emotion in the digital world—especially as brands adopt them to relate to customers. But people who rely on assistive reading technology might have a difficult time understanding content that relies on emojis to communicate its core message. So how can we make emojis accessible through our content design?

There’s a range of ways to approach this accessibility consideration, some of which involve a more significant effort than others. Let’s start with three key issues:

  1. When rendered as speech, an emoji’s default description may change the core message of its accompanying text.
  2. When spoken, an emoji’s default description may cause the message to omit critical information.
  3. Emojis with similar colors and shapes may be indistinguishable to people with varying levels of vision ability, even when using screen magnification.

Bumping into emojis

I started thinking about emojis during my first few weeks as a content design lead at Chime. The consensus was clear: Chime loves emojis and we were eager to learn more about using them as an element of content design.

So I started a conversation on Slack about Content Design London’s emoji guidelines:

  1. Never use emojis to replace words.
  2. Do not use emojis as the only way to express an emotion you intend to communicate.
  3. Use popular emojis that are widely recognized.
  4. Use emojis that translate well across devices.
  5. Put emojis at the end of sentences, and do not use repeated or too many emojis.
  6. Use emojis, not emoticons.
  7. Avoid emojis that are not visible in both dark and light modes.

As a group, we tried our hand at evaluating some moments when Chime uses emojis in-product against Content Design London’s guidelines.

From Brad Monahan

Just glancing at that message, the use of emojis deviates from guideline #5: Put emojis at the end of sentences, and do not use repeated or too many emojis. This consideration will have an impact when it comes to accessibility because of how the emojis might be read by screen readers. What is the alt text of these emojis and how would a screen reader speak this notification?

From Mike Homnick

I personally love the lightning bolt emoji example simply for how evocative it is and how consistently it’s used. That said, it could be deviating from guideline #2 about not using emojis as the only way to express emotions. If we could put words or an utterance to that emotion, what would it sound like? Oomph? Pow?

Design exploration by Aoni Wang

Emojis as bullet points is such a widely adopted content pattern that I’m surprised Content Design London’s guidelines don’t address it. How would a screen reader reading the alt text of these emojis sound? “Moneybag on March first get free boosts from Chime. Admission tickets boosts don’t rollover…”

“Admission tickets boosts” might be misinterpreted by a new member as an actual feature name, which could make the process of learning about Boosts more confusing than it needs to be.

Aha! Emojis can be confusing or difficult to understand for some users

After chatting for a bit, we realized that Chime members who rely on assistive reading technology may have a difficult time understanding content that relies on emojis to communicate its core message.

With this realization in mind, we decided to investigate emojis through the lens of three different types of assistive reading technology.

Screen readers

A screen reader converts text and image content into speech or braille. People who use screen readers might include those who are blind, visually impaired, illiterate, or who have different learning abilities. On mobile devices, screen readers will automatically read out an emoji’s default description.

Screen magnifiers

Magnification utilities allow people to enlarge specific areas on a screen. This type of technology makes content accessible to a wider range of vision abilities. Screen magnifiers can help people identify and distinguish between different types of emojis.

Large print

Increasing print size allows people with a range of vision abilities to comfortably see the words on their screen.

General data on screen reader usage

And while I can’t share any data on how many Chime members are using the technology listed above, here are some general data points that we discovered on a StackExchange conversation.

Screen reader usage data:

  • There are 326 million people in the US (source)
  • 88.5% of the US population uses the Internet (source)
  • 2.3% of the US population have a visual impairment (source)
  • 54% of those that are disabled go online (source, source)
  • 89.2% of people that use screen readers are disabled (source)

The problem goes beyond inconvenience

The impact of a poorly-designed emoji content experience has the potential to cause significant pain points for our members. Here are the three scenarios we surfaced:

Scenario #1

When rendered as speech, an emoji’s default description may change the core message of its accompanying text.

  • Written example: 🚫 No fees
  • Read by a screen reader: Prohibited no fees

Scenario #2

When spoken, an emoji’s default description may cause the message to omit critical information.

  • Written example: Make sure to 🧐  your Direct Deposit details for ⚡️ payments.
  • Read by a screen reader: Make sure to face with monocle your Direct Deposit details for zap payments.

Scenario #3

Emojis with similar colors and shapes may be indistinguishable to people with varying levels of vision ability, even when using screen magnification.

Example

Did you receive your card in the mail? [yellow shape][yellow shape]

Build emoji considerations into your design process

There’s a range of potential solutions to the problem of inaccessible emojis. Start a conversation with your design, product, research, and engineering partners to understand the best approach for your team.

At Chime, we identified a simple checklist as the first thing we can and should do. Here’s what it looks like:

  • Ensure the emoji isn’t being used to replace words
  • Ensure that the emoji isn’t the only way emotion is being expressed
  • Use popular, widely-recognized emojis
  • Use emojis that translate well across devices
  • Put emojis at the end of sentences, and don’t repeat them or use too many
  • Use emojis, not emoticons
  • Avoid emojis that are not visible in both dark and light mode

Once we’ve worked through the checklist, there’s one final step: Write out the message with the emoji’s default description — does it still convey the intended meaning and emotion? If it does, proceed. If not, write an accompanying accessibility label.

What can we do about it in the future?

Thanks to Lucy Liu, an engineer at Chime, we surfaced a variety of solutions that we can experiment with now and in the future.

Throughout these solutions, it’s important to consider the context of how your content is managed. For instance, if it’s hardcoded, it will be a lot easier to jam an accessibility label into it, but it comes with the downside of not being easily editable without an app update.

For server-driven content, you might build in the functionality to provide an accessibility label, but it would require some extra consideration and engineering work.

Provide coherent accessibility labels for screen readers

According to Lucy, screen readers will automatically read out an emoji’s default description. This is the default setting for most screen readers. However, we can tell the screen reader to read out a custom accessibility label instead. For instance:

<text accessibilityLabel=”Just kidding haha”>Just kidding 😂 </text>

Deliver accessibility labels alongside other languages

{ title:

{ en: “Just kidding 😂” },

{ es: “<es uno broma> 😂” },

{ ac: “Just kidding haha” },

}

Build a functional React emoji component to handle emojis

👋 ⚛️ — How to use emojis in React

import React from ‘react’;const Emoji = props => (

<span

className=”emoji”

role=”img”

aria-label={props.label ? props.label : “”}

aria-hidden={props.label ? “false” : “true”}

>

{props.symbol}

</span>);export default Emoji;

According to Lucy, “Our Emoji component takes two props: label and symbol. If present, the label is used to generate an aria-label, which will be read by a user’s screen reader. If absent, aria-label is left blank and aria-hidden is set to true. This means it will be ignored by the screen reader. This is a good practice if the emoji doesn’t add anything to the website other than a bit of flair. The symbol, which will be a string containing the emoji, is passed into the returned span. The role is the same in the previous example, and I added a class for styling.”

<ChimeEmoji symbol=”🐑” label=”sheep” size={16} />

<ChimeEmoji symbol=”🎟” label=”bullet point” size={20} />

Accessibility in the details

All of the explorations and solutions in this article represent just a small sliver of the work to be done through accessible content design. After all, this is just about emojis! But it can take time to get the details right, so start now! Taking every possible step toward more accessible content ensures that people with a range of abilities can use our digital products.

At Chime, we’ve built emoji accessibility considerations into our design processes, and our accessibility and inclusivity guild meets every week to ensure we’re taking steps forward, even the small ones.

Jason Fox is a growth content designer at Chime. Connect with him on LinkedIn!


Want to keep learning? Level up your UX writing and content design skills in one of our courses.

Comments are closed