Accessible Emoji, Tweaked

Léonie Watson recently posted Accessible Emoji, a simple technique to make emoji characters accessible to those with screen readers. It requires a little bit of extra effort when inserting an emoji into a web page, but it is worth it to convey the meaning to screen reader users.

Then there are users like me, who cannot tell when an emoji face is laughing or crying, or who cannot tell the difference between a peach and an eggplant emoji. You can imagine what this has done for my dating life.

Borrowing a little from a tool-tip-ish CSS-only example from Russ Weakley, I have enhanced Léonie’s example to make that handy aria-label display when the mouse hovers over the emoji. Add an unfortunate tabindex and now a keyboard-only user can put focus on the emoji.

I set bottom of the tool-tip relative to the top of the emoji, allowing for very long explanations that do not hide the emoji itself. I also use a bit of animation to make it visually more apparent from where the tool-tip is supposed to spring. If you find the animation is problematic for users you can just drop the reference and all works fine.

I included print styles so that even when printed users like me will benefit from the additional context for the emoji (or users like my parents who still print articles to read them). Which is a great reminder to never forget your print styles (I have written on this extensively).

The text scales with the base font size. Make sure the max-width limits the tool-tip from shooting out of the window. I did not include any Windows High Contrast Mode styles as the existing styles lend themselves well to be overridden.

Embedded Demo

If the embedded block below does not render, head on over to CodePen to play with it there or visit it in debug mode to see the print styles in action.

See the Pen Accessible Emoji by Adrian Roselli (@aardrian) on CodePen.

Unanticipated Bonus

When the device and/or browser does not recognize an emoji, your users can still get meaning with a tap or hover.

Screen shot from my mobile browser showing two of the emoji from my post represented as empty boxes. One of them has focus and has a tool-tip above it with the text “keyboard.”

Update: January 4, 2017

I was reminded that some operating systems allow folks to use emoji that are custom to that operating system, without telling the user that some other folks cannot see it. The tweet below shows how that is a problem. When building a web page, it is even more reason to make sure you provide alternative text.

In case Twitter is hosed, just view a screen shot of the image here (115kb PNG).

Update: April 1, 2017

For reasons, I made a video showing this all in action. If the embed does not work for you then grab the video directly.

The first part of the video demonstrates how it sounds when read by NVDA. The second part shows the interaction with a mouse. The third part shows the interaction with a keyboard.



Hi Adrian

Nice bit of code.

Does this only work if you hand code the emoji with the proper markup?

I was looking at emoji I had entered on my WordPress site and they show up in the browser inspector directly as entered. (I used CTRL-CMD-Space on Mac.)

<p>If there are no images, Facebook can’t add one. 🙂</p>

Whereas if I add a grinning face on Twitter, this is the markup generated:

<img class="Emoji Emoji--forText" src="" draggable="false" alt="😀" title="Grinning face" aria-label="Emoji: Grinning face">

In both cases, VoiceOver does seem to read out the emoji.

WordPress: slightly smiling face
Twitter: Emoji, Grinning face, image

Which do you think is the better implementation for a screen reader user?

In response to Claire Brotherton. Reply

Short answer, yes, you have to do this yourself in your HTML.

WordPress just presents the character and the screen reader is free to read through it as it sees fit. However, there are two risks with just a straight character entity as Léonie mentions in her post (that prompted this post):

  1. The first problem is that browsers do not always expose the emoji as an image in the accessibility tree.
  2. The browser may not automatically assign it an accessible name or an accessible description.

So it is not guaranteed to work for all browser / screen reader combinations.

Twitter bypasses that completely, and retains the ability to substitute its own branded emoji, by replacing the emoji character with an image. It then uses the title, alt, and aria-label to make it accessible to screen readers.

I forego title (as I do not care for using the attribute) in my example and lean on CSS generated content and a bit of other styling to mimic the effect.

As for which is the better approach, I leave that up to you to understand your audience, its skill level, its screen reader and browser combination, and the context for use of the emoji. It may be worth doing a little user testing if you have any user groups to borrow.

One additional note: the approach I outline gives you as the author the opportunity to add your own meaning, to give it more context or potentially confuse it even more. As I did with the bacon in my example.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>