WCAG 3.1.6 Pronunciation: When Websites Need to Support Correct Pronunciation

What WCAG 3.1.6 Pronunciation covers

WCAG 3.1.6 Pronunciation focuses on giving assistive technologies the information they need to speak words correctly. That includes names, acronyms, loanwords, technical terms and any text whose default pronunciation is wrong or unclear. Good support makes audio output easier to understand for people who rely on screen readers or text to speech.

Who benefits

• People who use screen readers and rely on spoken output to understand content
• Users with cognitive or reading disabilities who rely on clear spoken words
• Language learners who need accurate pronunciation cues
• People using automated voice assistants or phone-based interfaces that read site text

When to add pronunciation support

Prioritise pronunciation when incorrect speech changes meaning or makes content hard to follow. Common cases:

• Proper names that are not pronounced like they are written
• Acronyms and initialisms whose letter-by-letter reading is confusing
• Technical terms, product model codes and chemical names
• Words from a different language than the page language
• Unusual capitalisation or punctuation inside a word

Techniques to control pronunciation

Use the platform features that give speech agents the right cue without hiding content from other users.

1. Mark language with the lang attribute

Set a language on the element that contains a foreign word. A screen reader will switch pronunciation rules when it sees lang.

<span lang="fr">Bonjour</span>

2. Give an accessible name for speech with aria-label

Use aria-label to provide a phonetic respelling or a spoken form. Keep the visible text unchanged when the visible form matters visually.

<button aria-label="ess-en-vee-dee-ay">NVDA</button>

Test that the screen reader reads the label and not the visual text. If you hide the visual text with CSS, ensure the hidden content is still available to screen readers if needed.

3. Use <abbr> for acronyms and expansions

Wrap acronyms in <abbr> and include the expansion in the title attribute so some assistive tech can present the full form.

<abbr title="HyperText Markup Language">HTML</abbr>

4. Provide explicit speech markup to TTS where available

Cloud TTS services and voice platforms accept SSML to force pronunciation, stress and pauses. If you offer a TTS file or an audio fallback, include SSML or engine-specific lexicons.

Browser speech APIs differ. The Web Speech API exposes SpeechSynthesisUtterance with text and lang. Do not assume full SSML support in every browser. Prefer external TTS when you need advanced pronunciation control.

5. Use ruby annotations for East Asian pronunciation

For Chinese, Japanese or Korean text, <ruby> provides short pronunciation guides that native readers expect. Screen readers that support ruby will read the annotation as a pronunciation aid.

<ruby>漢字<rt>かんじ</rt></ruby>

6. Hide duplicate or helper text safely

If you add a phonetic respelling next to visible text, hide the duplicate from visual users but keep it available to screen readers. Use a reliable, accessible hiding technique rather than display:none if you want screen readers to read it.

Step-by-step implementation checklist

1. Identify problem terms across content. Export a glossary of names, acronyms and nonstandard words.
2. Set the page language and mark foreign words with lang.
3. Add aria-label or a screen-reader-only element for words that need phonetic respelling.
4. Use <abbr> for acronyms and <ruby> for East Asian text.
5. Where high-fidelity speech is required, generate TTS audio or use SSML with your TTS engine and serve it as an optional audio alternative.
6. Document every change in your content style guide or glossary so editors reuse consistent pronunciations.

Testing: what to check and how

• Listen with at least one Windows screen reader (for example NVDA or JAWS) and one Apple screen reader (VoiceOver). Also test TalkBack on Android if you support mobile.
• Check that the screen reader switches language when you set lang.
• Verify that aria-label or hidden phonetic text is read in place of the visual text when intended.
• Where you provide TTS audio, confirm the pronunciation with the actual engine you use. Engines differ in how they handle SSML and lexicons.
• Include testing with real users, especially native speakers of the target language and people who rely on screen readers.

Common mistakes and how to avoid them

• Relying on visual hints alone. A pronunciation note placed only in visible text will be missed by many screen reader users.
• Using title attributes as the only means to provide pronunciation. Some screen readers do not expose title consistently.
• Hiding text with display:none when you expect screen readers to read it. Use an accessible hiding pattern instead.
• Assuming all TTS systems speak the same. Test with the exact voices and engines your site uses.

Documentation for content teams

Create a short editor guide that covers:

• When to mark language and when to add an aria-label
• How to write a consistent phonetic respelling format
• How to add pronunciation entries to the central glossary and how to request new TTS recordings

Quick examples

Phonetic respelling with an aria-label while keeping visual text:

<span aria-label="zee-oh-ell">ZOL</span>

Foreign word marked with language:

<p>The French greeting <span lang="fr">bonjour</span> is common.</p>

Ruby annotation for Japanese:

<ruby>東京<rt>とうきょう</rt></ruby>

Keeping accessibility sustainable

Pronunciation work is most efficient when it is repeatable. Keep a shared glossary. Add checks to your content review workflow. Automate detection of unusual tokens with a script that flags capitalised runs, non-dictionary words and language-mismatched tokens for human review.

Summary

Support for correct pronunciation reduces friction for people who use spoken output. Use lang, aria-label, <abbr>, <ruby> and TTS where appropriate. Audit, document and test with real assistive technology to make sure the spoken form matches your intent.