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.