WCAG 3.1.3 Unusual Words: Making Complex Terms Easier to Understand

WCAG 3.1.3 Unusual Words: what this success criterion covers

WCAG 3.1.3 Unusual Words asks content authors to make complex, rare or specialised terms clear when they appear in user-facing text. Meeting 3.1.3 reduces confusion for people with cognitive disabilities, people learning the language, and screen reader users who rely on consistent wording. This article explains what counts as an unusual word, how to mark up or explain it, and practical steps teams can follow.

Which words are “unusual” under WCAG 3.1.3?

Unusual words include several categories you should check for every page:

• Technical terms and jargon used outside specialist contexts
• Acronyms and initialisms that are not widely known
• Obscure vocabulary and archaic words
• Idioms, metaphors, regional slang and culturally specific references
• Proper names, product codes or shorthand that require explanation

Why this matters for accessibility

People with cognitive or learning disabilities often need a clear definition the first time a term appears. Screen reader users benefit when definitions are accessible by keyboard and announced correctly. Search engines and translators also perform better when plain-language alternatives are available.

Practical ways to satisfy WCAG 3.1.3

Use the following methods in combination. Choose the option that fits the page context and the user’s needs.

• Provide an inline definition the first time the word appears, in parentheses or a short clause.
• Use a glossary page and link the first occurrence to a clear definition.
• Expose a short popover or expandable section that is keyboard focusable and screen reader visible.
• Use aria-describedby to associate a visible explanation with the phrase for assistive technology.
• Prefer plain language and replace unusual words with simpler alternatives when possible.

Example markup patterns

Two simple approaches developers can use. The markup here shows intent; adapt it to your framework.

Inline definition example: “The device uses biosensors (sensors that measure biological signals) to detect movement.”

ARIA association example: <span id=“term”>biosensors</span> sensors that measure biological signalsaria-describedby.

Testing WCAG 3.1.3: automated and manual checks

Automated tools can flag likely unusual words such as long camelCase tokens, excessive acronyms or words matching a jargon dictionary. They cannot decide whether a definition is adequate. Use a mix of tests:

• Automated scans to locate candidate words
• Manual review by writers or accessibility specialists
• User testing with people who have cognitive disabilities or who are non-native speakers
• Screen reader checks to confirm aria-describedby is announced and popovers are reachable by keyboard

Common implementation mistakes to avoid

• Relying only on the title attribute for definitions. The title attribute is not consistently announced and is inaccessible to many users.
• Hiding definitions with display:none or visibility:hidden. Hidden content is not exposed to assistive technology.
• Showing definitions that are themselves as complex as the term. The goal is clarity.
• Linking to a glossary page without a clear anchor or fragment; users should not have to search the glossary to find the definition.
• Updating content without updating the glossary or inline definitions; stale definitions cause confusion.

Writer workflow: step-by-step for editorial teams

1. Run a content scan to list potential unusual words on the page.
2. For each candidate, decide whether to replace the term with plain language. If not, add a short inline definition or glossary link at first use.
3. Write definitions at a reading level appropriate for your audience. Prefer short sentences and familiar words.
4. Confirm the definition is visible on small screens and announced by assistive tech.
5. Include the definition in the content management system so it persists across translations.

Developer checklist

• Ensure any popover or expandable definition is keyboard focusable and visible to screen readers.
• Use aria-describedby to link terms to their definitions when the definition is placed elsewhere on the page.
• Test with at least one screen reader and keyboard only navigation.
• Do not rely on CSS-only reveal techniques that remove the definition from the accessibility tree.
• Keep definition text in the DOM rather than injecting it only on click if the definition must be discoverable.

Examples and quick fixes

Unusual word	Simple fix
Onboarding	First use: onboarding (the process of starting with a product)
API	First use: API (application programming interface)
Clearing house	Replace with a plain phrase such as central registry or add a short explanation

Real-world scenario: a concise implementation pattern

Imagine a help article that uses the term “API” three times. Best practice:

• First use: show “API (application programming interface)”.
• On subsequent uses, keep the acronym but make sure a glossary link or aria-describedby remains available.
• If you expose a tooltip or popover, ensure it can be opened via keyboard and that it receives focus when opened.

Measuring success

Track a small set of metrics after you add definitions:

• User testing feedback specifically asking whether definitions were clear
• Support ticket volume for clarification questions on the topic
• Completion rates for tasks that rely on understanding the term

Summary checklist for WCAG 3.1.3

• Identify unusual words on each page
• Prefer plain language when feasible
• Provide a clear definition at first use or link to a glossary
• Make definitions keyboard and screen reader accessible
• Test with real users and update definitions after feedback

Following these steps makes content easier to understand and more usable for people who need extra clarity. Use the writer and developer checklists to build a reliable process so definitions are added consistently and tested regularly.