Accessible Emoji, Tweaked

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.

In response to Paul Grenier. Reply

Paul, It relies on aria-label for 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.

In response to J Redhead. Reply

If you use aria-label it will override all the content, even content you set via ::before/::after within that container. For what you are describing you could just use a structure like <span data-text="banana">🍌</span> and your CSS would be [data-text]::after { content: " (" attr(data-text) ")"; }.

No ARIA, no tool-tip, and the emoji and the ::after will both be announced by a screen reader, but it is an option that may be great for some contexts.

In response to Wojtek. Reply

To answer your first question, yes. Making them tab stops absolutely pollutes the page for keyboard users. But not making them tab stops keeps keyboard users from getting access to the text you add for the emoji. My overall suggestion is just don’t use emoji so you don’t need to make that decision.

Similarly, using a title attribute on <abbr> or <acronym> also excludes keyboard users. Generally I recommend against that pattern too.

So:

• Expand all abbreviations / acronyms as you would in printed text, eg: World Wide Web Consortium (W3C);
• Don’t use emoji in narrative text, but if you do then above is a technique to make them accessible.