✋ Accessible Emojis

Without Attributes

Screen readers use the emoji name as the default audio output when using text to audio software, which is much better than I had initially thought. However, emojis may be translated differently by different screen readers without role and aria-label attributes.

Without providing clear instructions through attributes, we could end up creating the wrong context entirely. It's almost like watching a film with slightly incorrect translations.

VoiceOver

Here are a few silly example sentences with VoiceOver (macOS screen reader software) using the "raise hand" emoji without role and aria-label attributes. The bottom statement is the only one that really makes sense when announced by this screen reader.

Emoji Wrapper Fix

TSX
1import React, { FC } from 'react';
2
3interface EmojiArgs {
4  label: string;
5  ariaHidden?: boolean;
6  emoji: string;
7}
8
9const Emoji: FC<EmojiArgs> = ({ label, emoji, ariaHidden = false }) => (
10  <span
11    className="emoji"
12    role="img"
13    aria-label={label}
14    aria-labelledby={label}
15    aria-hidden={ariaHidden}
16  >
17    {emoji}
18  </span>
19);
20
21export default Emoji;

TSX
1<Emoji emoji="✋" label="high five" />
2<Emoji emoji="✋" label="stop hand" />
3<Emoji emoji="✋" label="raise hand" />

Span Element

The span element is perfect to use since it represents an inline piece of content with no semantic meaning. A blank canvas we can add accessibility attributes to for our screen reader to interpret.

Role Attribute

The role HTML attribute helps screen readers inform the user about the element they've encountered on the page. In this scenario, the img role is used to treat the emoji as an image.

Aria-label Attribute

Aria labels are strings used to describe element content to the user. Aria labels should be used when no text is visible on the screen.

Aria-hidden Attribute

The aria-hidden attribute allows us to expose or hide non-interactive content from being created in the accessibility tree / accessibility API. The big list of emojis at the bottom of this article doesn't need to be exposed to assistive technology, it's purely "decorative". Adding aria-hidden="true" to this element removes it (and all of its children) from the accessibility tree.

More Errors

Additional accessibility issues were also caught, mainly around the interactivity of elements. For article overviews, I'm using article elements with onClick and onKeyPress event listeners. I'm not sure how to get around this error, an interactive element like a button isn't semantically correct considering I need to display additional details like keywords, published dates and average read times. I even had a look at the DOM structure over on Kent C. Dodds new site, which seems to be using mostly div elements on the blog section 🤷‍♂️.