WCAG 3.1.6 — Pronunciation

What this requires

A mechanism is available for identifying specific pronunciation of words where meaning is ambiguous without knowing the pronunciation. The criterion is rare to encounter in Latin-script text and more common in languages like Japanese, where the same characters can be read multiple ways and the reading affects meaning.

How AI coding tools fail this

This criterion is one of the least-encountered. The relevant failure for AI tools is generating Japanese content without ruby annotations, or pulling proper-name pronunciation out of unfamiliar names.

The broader failure: AI tools that generate speech (text-to-speech output) without a mechanism for the author to correct mispronunciations in published content. "Cache" pronounced "cash-ay", "Linux" pronounced "Lie-nux", and so on.

Passing examples

Ruby annotation showing the reading:

<p>
  <ruby>今日<rt>きょう</rt></ruby>は
  <ruby>晴<rt>は</rt></ruby>れです。
</p>

For Latin-script ambiguous words, an inline phonetic gloss on first use:

<p>
  The artisan bow (/baʊ/) is unrelated to the bow (/boʊ/) of a violin.
</p>

Edge cases

Ruby annotations in HTML use <ruby>, <rt>, <rp>. They render above the base text and are widely supported.
Japanese, Chinese, and Korean content has more frequent need for pronunciation aids — heterographic readings, place names, surnames.
Pronunciation guides for Latin-script Western languages are usually only needed for proper nouns or unusual words.
IPA notation is the international standard for phonetic transcription.
AAA scope. Most projects don't target this; it's a niche criterion most relevant to multilingual content.

How Jeikin handles this

This is a manual editorial review. The dashboard records, for projects with multilingual content or significant proper-name content, whether pronunciation aids are provided where needed. There's no scanner heuristic for this — the call is editorial.