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.
When the device and/or browser does not recognize an emoji, your users can still get meaning with a tap or hover.
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.
@aardrian “” is part of a private-use Unicode range, and on macOS and iOS, it renders as an Apple logo. http://www.liquisearch.com/mapping_of_unicode_characters/private_use_characters pic.twitter.com/GoQS4xEgwo— Ashley Bischoff (@FriendlyAshley) January 4, 2017
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.
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="https://abs.twimg.com/emoji/v2/72x72/1f600.png" 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?
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):
- The first problem is that browsers do not always expose the emoji as an image in the accessibility tree.
- 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
aria-labelto make it accessible to screen readers.
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.
Great idea here. Sadly, we still can’t get every browser/SR combo since it relies on CSS generated content. See https://www.powermapper.com/tests/screen-readers/content/css-generated-content/ for the most recent compatibility list I’ve found.
Paul, It relies on
aria-labelfor screen readers, not CSS generated content. Using the same resource (PowerMapper is great, BTW), the reliability trend for this approach puts it at 100% as of 2015.
So arguably we cannot get every browser/SR combo since they do not all support ARIA if we go back enough versions.
Are you suggesting that there is a better approach? If so, I am all ears.
Adrian, Brilliant! I totally missed the aria-label.