When Emojis Become Noise: Guide for Accessible Use in Course Content
Why emojis and icons might not work for everyone, and how to fix it. Digging into how screen readers announce them to learn when to hide them entirely.
A tendency I started noticing lately is a wider usage of emojis or icons in contexts where just recently they were not common at all. My feeling is that at least part of the reason is that a lot of AI tools, being text-based, try to break-up the text and make it more visually appealing. I’m not saying that emojis are a clear marker of an AI-generated text (after all, the m-dash has that honorable title). Rather, they’ve become seen as helpful signposts. While in the past emojis were mostly seen as a marker of less formal communication, making their way from text messages to social media, their inclusion in corporate communication and educational materials is more recent. I’ve seen newsletters, internal memos and course announcements suddenly peppered with 📊 and ✅ symbols.
Too much of a good thing
What some might not realise is that those helpful-looking images might be making things easier for some learners, while leaving others behind. I recently collaborated with learning designers on improving the look of a Moodle course template. Accessibility is always one of the key considerations, so I have been consulting information on the best way to use such emojis or icons that is accessible. Here’s what I learnt on making emojis and icons truly inclusive.
The decorative dilemma
I’ve always been bothered by that “decorative” checkbox in Moodle image upload interface - which images are considered decorative? It gets harder when it’s not an image, but part of the text. I found myself staring at text like 🕐 Time: 1pm or ✉️ Email: email@example.com and wondering whether I finally encountered a case where images were purely decorative. One was an emoji, another an icon, but this time there was no checkbox to tick.
I started digging into how these things are treated by screen readers. I found a video where Molly Burke, a digital creator and accessibility advocate (who also happens to be blind), demonstrates how the screen reader reads emojis. Imagine hearing “one o’clock time 1 pm” or “envelope email link” - suddenly what was meant to be helpful becomes redundant noise.
What I Learned: A Three-Step Approach
After all this digging, I’m trying to think of it in these steps:
- Check how your emoji and text combination will look and sound for both visual users and screen reader users. You might find that 🕐 Time: 1pm becomes the unhelpful “one o’clock time 1 pm,” while 📧 email@example.com is more acceptable as it is voiced as “envelope email@example.com.”
- Check how emojis actually sound. Resources like Emojipedia can help check the “official names” for emojis - that’s what screen readers will use. Some are clear and can stand on their own, eg ✅ is “check mark button” but an image of a lightning ⚡which might be used to draw attention to something is officially called “high voltage sign”. You might even want to replace an emoji for one that’s similar in look, but has a more appropriate or clearer name.
- Finally, hide redundant elements.
aria-hidden="true"will make visual elements hidden from screen readers, letting their users get uncluttered content, while still retaining visual signposts for visual users. You’ll need to switch to HTML source mode in Moodle’s editor to add this code (I really wish Moodle made accessibility more accessible for learning developers):<span aria-hidden="true">🕐 </span>Time: 1pm
The Bottom Line
This way, we have the best of both worlds: we’re not adding noise for screen reader users, while still visually breaking up text and adding signposts for others. (Though we might end up overwhelming neurodivergent users with visual images interspersed in text - but that’s another accessibility rabbit hole I am tempted to go down one day)
