On each web page, does each cryptic content (ASCII art, emoticon, cryptic syntax) have an alternative?
A screen reader reads ":-) " as "colon dash right parenthesis". For someone who depends on a screen reader, this sequence of punctuation marks communicates nothing. This is the problem targeted by criterion 13.5: certain characters are used not for their literal value, but to represent a drawing, an emotion, or a coded word.
Three categories are addressed: ASCII art (drawings made with characters, such as ¯\_(ツ)_/¯), text emoticons (:-), :D, <3, ^_^) and cryptic syntax such as leet speak (h4ck3r, l33t). If any of this content appears on your page and conveys information, it must have an understandable alternative.
Two solutions are accepted by RGAA: a title attribute on a wrapping element (<abbr>, link, form control), or a textual definition placed immediately before or after the cryptic content in the page flow. No alternative, no conformance.
Un test to assess the understandability of cryptic content
Alternative text for each cryptic content
- Browse the page and identify all cryptic content: ASCII art, text emoticons (
:-),:D,<3…) and cryptic syntax (leet speak, etc.). - For each content found, verify one of the following two conditions:
- A
titleattribute is present on a wrapping element (<abbr>, link, form control) and provides the definition in clear text. - An explanatory text is placed immediately before or after the cryptic content in the page flow.
- A
- If at least one cryptic content satisfies neither of these two conditions, the test fails.
Examples
❌ Non-compliant : Emoticon without alternative
<p>Thank you for your message :-)</p>The screen reader vocalizes "colon dash right parenthesis". The user must decode alone that this is a smile — this decoding is impossible for those who do not know text emoticon conventions.
✅ Compliant : Emoticon with abbr and title
<p>Thank you for your message <abbr title="smile">:-)</abbr></p>The screen reader exposes the title and reads "smile" instead of the punctuation sequence. The emotional intent of the message is conveyed without the user having to decode the symbols.
✅ Compliant : ASCII art hidden with visible adjacent definition
<p>Confidence level: <span aria-hidden="true">¯\_(ツ)_/¯</span> (I don't know)</p>The ASCII art is hidden from assistive technologies via aria-hidden="true", and a textual definition follows immediately in parentheses. Sighted visitors read the symbol; screen reader users hear the meaning. Double benefit.
❌ Non-compliant : Leet speak without alternative
<p>Welcome to the site of the <span class="highlight">h4ck3rz</span>!</p>The screen reader spells out the characters one by one: "h, 4, c, k, 3, r, z". Without a title or adjacent text, the user does not understand that this is the word "hackers", and the meaning of the sentence is lost.
Tips and pitfalls
⚠️ Confusing Unicode emojis and text emoticons
Unicode emojis (😊, 👍) are not cryptic content in the sense of criterion 13.5. Each emoji has an official description in the Unicode standard that screen readers vocalize. Text emoticons (:-), :D) are another category: they are sequences of punctuation marks without Unicode semantics, and it is these that this criterion addresses.
⚠️ Neglecting user-generated content
Comment areas, forums, and chat fields are within the audit scope. If your platform displays ASCII art submitted by users without marking it, this is non-conformance. Two options: filter cryptic sequences at input, or automatically transform known emoticons into <abbr title="..."> on display.
⚠️ Unicode Private Use Area characters are outside the scope of this criterion
Unicode ranges U+E000–U+F8FF and U+F0000–U+FFFFF (PUA) are used by certain icon fonts and platforms such as Moodle. These characters are not cryptic content in the sense of criterion 13.5. If they convey information, criterion 1.1 applies: an aria-label on the element is sufficient to render the content compliant.
💡 Combining aria-hidden and adjacent definition: the most robust technique
Rather than letting the screen reader vocalize a chaotic sequence before reaching the title, hide the cryptic content with aria-hidden="true" and place the definition in visible text immediately after. You satisfy criterion 13.5 and offer a coherent experience, whether or not the user employs assistive technology.
⚠️ Title on a generic span: risky in practice
RGAA methodology mentions links, form controls, and <abbr> as valid bearers of the title. An ordinary <span title="..."> is technically acceptable, but several screen readers do not expose the title of non-interactive elements without specific configuration. Prefer <abbr> for non-standard terms: it is the semantically appropriate element and its title is exposed consistently.
Frequently asked questions
How does RGAA criterion 13.5 apply to emojis (😊, 🎉)?
No. Unicode emojis have an official description that screen readers vocalize automatically. They fall under criterion 1.1 if they carry information: then verify that the Unicode description is sufficiently explicit in context, or supplement it with an aria-label. Criterion 13.5 concerns only sequences of ASCII characters used as visual codes (text emoticons, ASCII art, leet speak).
How do I make text emoticons compliant with RGAA criterion 13.5?
One alternative is sufficient. RGAA does not forbid emoticons; it requires them to be understandable by all. An <abbr title="smile">:-)</abbr> or adjacent text ":-) (smile)" renders the content compliant without removing the expressive character of the symbol.
How do I effectively detect cryptic content during a RGAA audit?
Search the source code for typical sequences: :-, :D, <3, ^_^, as well as the alternating digit-letter patterns characteristic of leet speak. Also inspect visually editorial areas and user comments. For each occurrence, verify the presence of a title on a wrapping element or explanatory adjacent text.
In what cases does RGAA 13.5 apply to hidden or off-screen content?
No. The criterion applies to content presented to the user. Content hidden with display: none or visibility: hidden is not rendered by assistive technologies and is out of scope. However, content positioned off-screen via CSS but still in the accessibility tree (sr-only technique) remains in scope.
How does RGAA 13.5 treat passwords masked with *?
This is a borderline area. Masking characters (•, *) are standard functional representations of password fields: screen readers vocalize "protected character" or equivalent depending on implementation. The RGAA knowledge base indicates that criterion 13.5 may apply in the absence of a more specific test, but this use case is generally covered by form criteria (11.x).