WCAG 3.1.6: Pronunciation
Read this aloud: “The soldier decided to desert in the desert.” Same letters, two words, two pronunciations — and if you hear the wrong one, you get the wrong meaning. This criterion says: when a word’s meaning is ambiguous without knowing its pronunciation, provide a mechanism that reveals the pronunciation — ruby annotations, glossary links, phonetic spellings, or audio.
The success criterion, in full
A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation.
The load-bearing phrase is in context. Most heteronyms are disambiguated by their sentence — “she plays bass guitar” needs no help. The criterion fires only when the surrounding words still leave the meaning genuinely uncertain.
Who this helps
Text-to-speech and screen reader users
A synthesizer must pick one reading of an ambiguous word, and it guesses from statistics, not understanding. When it guesses wrong, the listener receives the wrong meaning with no visual spelling to fall back on.
People with reading disabilities
Many readers decode by sounding words out. A word with two plausible sounds and two meanings can halt comprehension entirely; a pronunciation cue resolves it instantly.
Deaf and hard-of-hearing readers
Readers who have never heard a word pronounced can't use sound memory to disambiguate. Explicit pronunciation information supplies what incidental listening supplies for hearing readers.
Language learners and cross-script readers
In Japanese, one kanji compound can have several readings with different meanings — furigana (ruby) is the centuries-old fix. Learners of any language face the same trap with heteronyms and names.
This is one of the most language-dependent criteria in WCAG. In English it fires occasionally; in Japanese, Chinese, Hebrew, and Arabic — languages where the written form routinely underspecifies the sound — it is a daily concern, and native conventions (furigana, pinyin, niqqud, harakat) are the established mechanisms.
What triggers the requirement
Work through three questions for any suspicious word:
- Does the word have multiple pronunciations with different meanings? If not — even a strangely spelled word with one reading — 3.1.6 does not apply (3.1.3 Unusual Words may).
- Does the context fail to resolve which one is meant? “He caught a bass” is resolved by “caught.” “Turn up the bass” is resolved by “turn up.” But a heading that just says “Bass” on a sporting-goods page that also sells speakers is genuinely ambiguous.
- Is a mechanism available for that word? Inline pronunciation, ruby annotation, a glossary link with pronunciation, a page-level pronunciation guide, or a playable audio clip. Any one of them satisfies the criterion; there are no other exceptions to fall back on.
The cheapest conformance strategy is editorial: rewrite to remove the ambiguity (“the sea bass”, “the bass line”). When the ambiguous form must stay — proper names, quoted text, poetry, kanji — reach for a mechanism.
Pass and fail examples
✓ Passes 3.1.6
- A Japanese news site rendering unusual kanji readings with furigana via
<ruby>. - A poetry archive that links ambiguous words to a glossary showing IPA and a play-audio button.
- A surname guide writing “Nguyen (pronounced ‘win’)” inline on first use.
- A page whose only heteronyms are fully resolved by their sentences — no mechanism needed, criterion satisfied by context.
✗ Fails 3.1.6
- A dictionary-style entry titled just “Bow” covering both the knot and the ship part, with no pronunciation for either sense.
- Japanese text using rare kanji readings with no furigana, glossary, or audio anywhere.
- A quiz question — “What does ‘wind’ mean?” — where the answer depends on the reading and no mechanism identifies it.
- A pronunciation guide that exists but omits the actual ambiguous words used on the page.
Code: ruby, glossaries, and audio
Ruby annotation for per-character readings
<ruby> renders small annotation text above the base characters — the standard technique for Japanese furigana, and usable for phonetic hints in any script. <rp> supplies parentheses for browsers that cannot render ruby.
<!-- Japanese furigana: 東京 read as とうきょう -->
<p>
<ruby>東京<rp>（</rp><rt>とうきょう</rt><rp>）</rp></ruby>
は日本の首都です。
</p>
<!-- The same element carrying a phonetic hint in English -->
<p>
The <ruby>ye<rp>（</rp><rt>the</rt><rp>）</rp></ruby> in
"Ye Olde Shoppe" was always pronounced "the".
</p>Inline pronunciation on first use
The simplest sufficient technique: state the pronunciation in plain text immediately after the ambiguous word. It works everywhere, needs no special support, and benefits every reader.
<p>
The fishing report covers striped bass
<span class="pronunciation">(pronounced "bass" as in "class")</span>,
not the bass <span class="pronunciation">(rhymes with "base")</span>
you hear in music.
</p>Glossary link with audio pronunciation
For recurring terms, link each ambiguous word to a glossary entry that shows the phonetic form and offers a sound file. Remember a text alternative for the audio itself.
<p>
Sailors salute from the
<a href="/glossary#bow-ship">bow</a> of the ship.
</p>
<!-- /glossary#bow-ship -->
<dt id="bow-ship">bow <span aria-hidden="true">/baʊ/</span>
<span class="sr-only">pronounced "bau", rhyming with "cow"</span>
</dt>
<dd>
The front end of a ship.
<button type="button" data-audio="/audio/bow-ship.mp3">
Play pronunciation
</button>
</dd>Common failures
- Leaving genuinely ambiguous heteronyms bare where context cannot resolve them — headings and single-word labels are the classic spot.
- Publishing Japanese or Chinese content with unusual readings and no furigana, pinyin, glossary, or audio mechanism at all.
- Providing IPA notation only, with no plain-language respelling or audio — IPA is itself unreadable to most of the audience that needs help.
- A site pronunciation guide that does not include the specific ambiguous words actually used in the content.
- Relying on aria-label to force a screen reader pronunciation — this changes what is announced for AT users but gives visual readers no mechanism, and often corrupts braille output.
- Audio pronunciation buttons with no text alternative or transcript, trading one accessibility gap for another (see 1.1.1).
How to test for 3.1.6
- 1
Inventory candidate words
Scan the content for heteronyms and, in relevant languages, characters with multiple readings. For English, a checklist of common heteronyms (bass, bow, desert, lead, tear, wind, wound, minute, dove, row…) catches most cases; content in Japanese or similar scripts needs a native-speaker pass.
- 2
Judge each occurrence in context
For every candidate, read the full sentence and surrounding content. If a reasonable reader (or a text-to-speech engine) could still pick the wrong pronunciation and therefore the wrong meaning, the occurrence is in scope.
- 3
Listen with text-to-speech
Run the page through a screen reader or TTS engine and listen for the in-scope words. A synthesizer choosing the wrong reading is direct evidence the ambiguity is real — and shows exactly what an audio-first user experiences.
- 4
Verify a mechanism exists for each in-scope word
Check for inline pronunciation, ruby annotation, a glossary link that includes pronunciation, a page/site pronunciation guide covering the word, or a playable audio clip. One mechanism per word is enough.
- 5
Verify the mechanism itself is accessible
Ruby should degrade gracefully (<rp> fallbacks), audio needs a text equivalent, glossary links need descriptive text, and any popover mechanism must be keyboard-operable and meet 1.4.13.
No automated tool can detect meaning ambiguity — this is a human, editorial review. Track it alongside the rest of your WCAG 2.2 checklist.
Relationship to other criteria
The Readable guideline works as a pipeline from sound to sense. 3.1.1 Language of Page (A) and 3.1.2 Language of Parts (AA) tell the speech synthesizer which language rules to apply — the single biggest pronunciation win available, and a prerequisite: no per-word mechanism can rescue a page whose whole language is declared wrong. 3.1.3 Unusual Words and 3.1.4 Abbreviations (both AAA) handle meaning; 3.1.6 handles the cases where the sound is the missing key.
It also pairs naturally with 3.1.5 Reading Level (AAA) — the same glossary infrastructure serves both — and any audio pronunciations you add must themselves meet 1.1.1 Non-text Content (A) with text equivalents.
Frequently asked questions
What does WCAG 3.1.6 Pronunciation require?
It requires that a mechanism is available for identifying the specific pronunciation of words where the meaning of those words, in context, is ambiguous without knowing the pronunciation. It is a Level AAA success criterion under Guideline 3.1 Readable. The trigger is narrow: it applies only when context does not resolve the ambiguity — when even a full sentence read around the word still leaves two possible meanings that differ by pronunciation alone.
Which words does 3.1.6 actually apply to?
Heteronyms — words spelled identically but pronounced differently with different meanings — when context leaves them ambiguous. English examples: 'desert' (abandon vs. arid land), 'bass' (fish vs. low frequency), 'bow' (of a ship vs. ribbon), 'tear', 'lead', 'wind'. The criterion matters even more in languages like Japanese, where the same Han (kanji) characters can have multiple readings, which is why ruby annotation exists. If the sentence makes the meaning obvious, no mechanism is needed for that occurrence.
What counts as a 'mechanism' for identifying pronunciation?
Any of: pronunciation given inline right after the word (e.g. 'bass (pronounced "base")'), ruby annotations over the characters, a link from the word to a glossary entry that includes pronunciation, a pronunciation guide for the page or site that covers the word, or a sound file the user can play to hear the word spoken. The Understanding document lists all of these as sufficient techniques — you only need one per ambiguous word.
Why does pronunciation matter for accessibility rather than just style?
Because some users receive the text as sound or must reconstruct sound to decode it. Screen reader and text-to-speech users hear one pronunciation chosen by the synthesizer — if it picks the wrong reading of an ambiguous word, the meaning silently changes. People with reading disabilities may sound words out and stall on ambiguity. Deaf and hard-of-hearing readers, and people reading in a second language, can misassign meaning without a pronunciation cue. The mechanism restores the information the spelling alone fails to carry.
How does ruby markup work, and do screen readers support it?
The HTML <ruby> element wraps base text, and <rt> carries the annotation rendered above it: <ruby>漢字<rt>かんじ</rt></ruby>. <rp> provides fallback parentheses for browsers without ruby rendering. Browser visual support is excellent. Screen reader behavior varies — some read the base text, some the annotation — so for critical content pair ruby with another mechanism such as a glossary entry or audio clip. Ruby is standard practice for Japanese furigana and useful for phonetic guides generally.
How is 3.1.6 different from 3.1.3 Unusual Words and 3.1.4 Abbreviations?
All three are AAA criteria in the Readable guideline that require mechanisms for understanding words, but they cover different problems. 3.1.3 covers words used in an unusual or restricted way (jargon, idioms) — the reader needs a definition. 3.1.4 covers abbreviations — the reader needs the expanded form. 3.1.6 covers pronunciation-dependent meaning — the reader needs to know how the word sounds. A single well-built glossary can satisfy all three at once if entries include definitions, expansions, and pronunciations.
Related Success Criteria
The default human language of each page can be programmatically determined.
The human language of each passage can be programmatically determined.
A mechanism is available for identifying specific definitions of words.
A mechanism for identifying the expanded form of abbreviations is available.
Text requires reading ability no higher than lower secondary education level.