Question:
How should we handle character entities in the alt attribute?
If you want to ask me a question and have me answer it here, please go to this a11y.email questions google form. This is a no-judgment way to get your questions answered!
Answer:
This question came in via a coworker a while back and I think it’s a good basic that’s worth talking through.
Earlier in my career, I was taught to use weird text versions of business-related character entities in the alt attribute. I was told that alt attributes could only have “plain text” and that special characters did not work. So the registration mark would be (R) or the copyright was (C) – I did this so regularly and thought it was the “correct” thing to do so that when someone asked me how screen readers read character entities I realized I had never actually checked. (This was the beginning of my “test before answering” process, lol)
Partly because I thought it was a weird question, and partly because I realized I was making an assumption without any basis for insights – I actually did test character entities in the alt attribute. In my testing I found that character entities are read out the same way in live text vs alt text. So you are safe to use ® and © in your alt text just like you do in your live text.
Be aware though, there are some character entities that are historically bad news for screen readers – I discovered this when I tested hawaiian diatrics, some of the screen readers I tested did some wonky stuff like say “upside down apostrophe” for the okina diatric. That is not good. Doing some quick googling – screen readers are so bad at hawaiian diatrics that Oahu’s Metro Planning Organization just flat-out doesn’t use them because it’s such a bad experience for site visitors that use screen readers.
For the most part – your registration mark, your trade mark, your copyright sign, are going to be read just fine by screen readers. They work similarly to emojis in that there is a “set” way that screen readers read them and so it’s important to understand how they are read.
Example:
You want to use a “surprised face” in your subject line so you use this guy: 😮
But the description that the screen reader reads will be “Face With Open Mouth”
Or maybe you meant this guy? 😯
Which is a little closer with “Hushed Face”
What you probably want is this guy: 😲
Which is read like “Astonished Face”
This works similarly with character entities:
Designers love to use this character (›) at the end of a link to indicate that the link is going somewhere. (This would actually be a good place for an underline to distinguish the link but I digress)
But the › character actually reads “single right-pointing angle quotation mark”
So in this situation – even though I am forever and always team live text, you might be better off making this an image – and if you’re placing this image within the link (as you should) – then you won’t even need any alt text. A+++ just make sure you envelope that character in the background color so it’s visible in dark mode.
These set readouts happen when they’re used in live text and in alt text, there isn’t a functional difference on them at all.
One quick note since I’ve already walked us into live text and emojis and special characters: in the web world it is often suggested to use a span wrapper with an aria-label to provide the accessible name. That’s a great solution for the emoji example above, you can just have an aria-label that says “Surprised face”. BUT – as in all things email and aria, the actual results of these aria attributes are not always read out the way that they should be. In most of my attempts to use an aria-label in this scenario, it is not read at all. Sometimes the aria-label is read before or after the standard description. Sometimes it actually works as expected and the aria label is read instead of the standard description. All that to say – your best solution is to choose your emojis and special characters by their actual name/description, not how they look visually.
(Brief pause for our designer friends) Sorry I guess?
So – the best way to use character entities (and emojis!) is to actually use the encoded character entity just like you do in live text. It’s always best to test non-standard character entities to know how they are actually read – and it’s always a good idea to look up the name/description of those emojis and character entities to make sure you’re communicating what you think you’re communicating.