On each web page, for each cryptic content (ASCII art, emoticon, cryptic syntax) that has an alternative, is this alternative relevant?

A screen reader encountering ":--)" without an alternative reads the three characters one by one. If an alternative is provided but states ":--)" or "emoticon", the user is no better off. This is exactly what this criterion checks.

Criterion 13.5 asks whether cryptic content has an alternative. Criterion 13.6 goes further: does this alternative truly convey the meaning? An emoticon ";-)" with title=";-)" is not relevant. An alternative that says "knowing wink" is.

Three types of content are concerned: ASCII art (visual representations made of characters), emoticons (sequences of punctuation like :-) or :-D), and cryptic syntax like leetspeak. For each, the alternative must convey the actual meaning — not describe the form, not copy the characters.

Un test to verify the relevance of the alternative to cryptic content

Relevance of alternative of cryptic content

  1. Identify all cryptic content on the page: ASCII art, emoticons (:-), :-D, ;-), etc.), leetspeak and other non-standard syntax.
  2. For each cryptic content, identify the alternative provided: title attribute, aria-label, alt if encoded as image, or immediate adjacent text.
  3. Verify that this alternative expresses the meaning of the content — not its raw characters, not its format, but what it signifies. A smiling emoticon should have an alternative meaning "smile" or equivalent.
  4. If all alternatives are relevant, the test is validated. A single piece of content with a non-relevant alternative fails the test.

Examples

❌ Non-compliant : Emoticon with alternative repeating characters

<abbr title=":-)">:-)</abbr>

The title attribute simply copies the emoticon's characters. A screen reader will read "colon, hyphen, closing parenthesis" — no meaning conveyed. The criterion requires that the alternative express what the content signifies, not what it represents graphically.

✅ Compliant : Emoticon with relevant alternative

<abbr title="smile">:-)</abbr>

The screen reader user hears "smile" instead of the three characters. The same logic applies to leetspeak: <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr> is correct because the title gives the readable and comprehensible form.

❌ Non-compliant : ASCII art with alternative describing format

<pre aria-label="ASCII art">
  /\_/\
 ( o.o )
  > ^ <
</pre>

aria-label="ASCII art" describes the content's format, not what it represents. The user knows it is ASCII art, but doesn't know it's a cat. It's the same error as putting alt="image" on a photo.

✅ Compliant : ASCII art with descriptive alternative of subject

<pre role="img" aria-label="A cat sitting, viewed from the front">
  /\_/\
 ( o.o )
  > ^ <
</pre>

The aria-label describes what the ASCII art represents. The screen reader announces "A cat sitting, viewed from the front", conveying the visual information without the user having to decipher the characters one by one.

Tips and pitfalls

⚠️ Repeating characters in the alternative

This is the most frequent error in audits: putting title=":-)" or aria-label=":-D". The alternative must express meaning, not copy the form. "Smile", "big smile", "wink" — those are relevant alternatives.

⚠️ Naming the format rather than the meaning

aria-label="emoticon" or alt="ASCII art" informs the user of the content type, not its meaning. It is not relevant under criterion 13.6. A relevant alternative answers the question "what does this content mean?", not "what type is it?"

💡 Unicode emojis are not ASCII emoticons

Unicode emojis (😊, 👍, 🎉) benefit from automatic vocalization by screen readers via their Unicode name ("smiling face"). ASCII emoticons like :-) or :-D do not benefit from this treatment: they require an explicit alternative. Do not confuse the two in your audit.

⚠️ User-generated content

If your site allows input containing emoticons — comment threads, messaging, forums — it's your responsibility to implement automatic conversion. A system that displays :-) without transforming it into <abbr title="smile">:-)</abbr> does not satisfy criterion 13.6, even if you did not input this content yourself.

⚠️ 13.5 and 13.6: two criteria to audit separately

Criterion 13.5 verifies the existence of an alternative. Criterion 13.6 verifies its relevance. Cryptic content without any alternative fails only 13.5. Content with a non-relevant alternative fails both. Track them separately in your audit report.

Frequently asked questions

How do you practically test the relevance of text alternative according to RGAA?

Read the alternative without looking at the cryptic content. Do you understand what the author intended to express? If yes, it is relevant. If you need to see the original content to interpret the alternative, it is not. This is the RGAA's simplest test.

In what case does adjacent text constitute a valid alternative under RGAA?

Yes, according to WCAG technique H86: text placed immediately before or after cryptic content can serve as an alternative, provided it is relevant. "We are delighted to welcome you :--)" is not sufficient because "delighted" contextualizes without explicitly clarifying the emoticon. Text like ":-) [smile]" would be acceptable.

How do you audit emoticons in RGAA: by individual occurrence or by type?

Each occurrence. The same emoticon :-) can have nuances depending on context: in a condolence message, its alternative should reflect this shift in tone. Test 13.6.1 requires verifying each piece of cryptic content individually.

What difference distinguishes WCAG techniques F71 and F72 for cryptic alternatives?

F71 covers the failure for emoticons and ASCII art whose alternative repeats characters without conveying their meaning. F72 specifically covers leetspeak. In practice, both describe the same error: an alternative that does not convey the actual meaning of the cryptic content, regardless of its type.

Why audit leetspeak in RGAA even when it is absent from pages?

As soon as cryptic content is present, it must have a relevant alternative — RGAA makes no exception for rarity. A video game page, community forum, or brand site may well contain it. Technique H86 gives the reference example: <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr>.

References