WCAG 3.1.3: Unusual Words

What This Rule Means

WCAG 3.1.3 — Unusual Words is a Level AAA success criterion under the Understandable principle. It requires that any web content using words or phrases in an unusual, specialized, or restricted sense must provide a mechanism that allows users to look up or access the definitions of those terms. This applies to three categories of language use: jargon (specialized vocabulary specific to a trade, profession, or field), idioms (phrases whose meaning cannot be inferred from the literal meaning of the words, such as "break a leg" or "hit the ground running"), and words used in a restricted or unusual way (common words assigned a specialized or non-standard meaning in a particular context).

The criterion does not mandate a single implementation approach. Acceptable mechanisms include inline definitions, a glossary linked from the page, tooltips or expandable definitions triggered by user interaction, definitions provided in the surrounding text, or the use of the HTML <dfn> element paired with accessible context. The key requirement is that the definition mechanism must be available — users must be able to reach it without undue effort.

A pass is achieved when every instance of jargon, idiom, or unusually-used word on the page is accompanied by a reachable definition mechanism. A fail occurs when specialized or ambiguous terminology appears without any such mechanism — for example, a legal website that uses terms like "tortfeasor" or "subrogation" without a glossary or inline explanation.

WCAG does define a narrow exception: if a word is used in an unusual way only within a specific passage, it is sufficient to provide the definition for that passage rather than globally across the entire site. Additionally, proper nouns (names of people, places, or organizations) are generally not subject to this criterion unless they double as technical terms in context.

Why It Matters

Language comprehension barriers affect a remarkably wide range of users. People with cognitive disabilities — including dyslexia, intellectual disabilities, and acquired brain injuries — may struggle to infer meaning from context when unfamiliar terms appear. According to the World Health Organization, approximately 1 in 6 people worldwide live with some form of disability, and cognitive impairments represent one of the largest categories. For these users, encountering undefined jargon can make an otherwise accessible page completely unusable.

Non-native speakers represent another major group affected by this criterion. In Turkey alone, the population includes millions of people whose first language is Kurdish, Arabic, or another regional language, and who may read Turkish as a second language. When a Turkish government health portal uses medical terminology like "anjiyoplasti" or "antikoagülan" without explanation, these users — and even many native Turkish speakers — may be unable to understand critical health information.

Screen reader users are also affected in a subtle but meaningful way. When a term is defined via a visible tooltip or glossary, sighted users can quickly scan for it. However, if that mechanism is not keyboard-accessible and programmatically determinable, blind users relying on assistive technology may never reach the definition at all. Providing well-structured inline definitions or a properly linked glossary ensures parity of access.

Consider a concrete scenario: a Turkish e-commerce platform sells financial products and uses the term "faiz oranı bileşimi" (compound interest) without explanation. A user with an intellectual disability, or an elderly user unfamiliar with finance, attempting to compare loan products may make a financially harmful decision simply because the terminology was never clarified. Providing a linked glossary or an accessible tooltip with a plain-language definition directly mitigates this risk.

Beyond accessibility, this criterion has measurable usability and SEO benefits. Glossary pages indexed by search engines increase topical authority and can capture long-tail search traffic. Clear definitions also reduce customer support burden, improve conversion rates, and contribute to overall content quality — all outcomes relevant to commercial operators.

Related Axe-core Rules

WCAG 3.1.3 falls into the category of criteria that require manual testing. There is no automated axe-core rule that can detect whether unusual words are defined, because doing so would require the tool to understand the semantic meaning and domain context of every word on a page — a task that exceeds current automated analysis capabilities.

• Manual evaluation required — Unusual Words: Automated accessibility scanners such as axe-core, Lighthouse, and IBM Equal Access Checker cannot identify which words qualify as jargon, idioms, or unusually-used terms, because this determination depends on domain knowledge, audience context, and linguistic interpretation. A scanner cannot know that "token" means a security credential in one context and a voucher in another, or that "cloud" refers to distributed computing infrastructure rather than atmospheric water vapor. Human reviewers — ideally including members of the target audience — must read the content and assess whether any terminology requires definition. The reviewer should then verify that an accessible definition mechanism exists for each flagged term.
• Complementary automated checks: While axe-core cannot evaluate this criterion directly, auditors can use automated tools to verify that any definition mechanisms used (such as <dfn> elements, tooltips, or linked glossaries) are themselves accessible. For instance, axe-core rules covering link purpose (link-name), keyboard accessibility (tabindex), and ARIA usage (aria-allowed-attr) can confirm that a glossary link or tooltip widget is properly implemented — even if the tool cannot judge whether the glossary is complete.

How to Test

1. Automated pre-scan: Run axe DevTools or Lighthouse on the page to confirm there are no baseline accessibility failures that might interfere with testing (broken links, missing focus indicators, etc.). Note any interactive definition widgets (tooltips, expandable terms) flagged for ARIA or keyboard issues. These secondary failures can prevent users from reaching definitions even when they exist.
2. Content audit — identify unusual terms: Read through the page content carefully. Flag every instance of jargon, technical terminology, idiom, or word used in a non-standard sense. It helps to imagine explaining the page to a user with no background in the subject area. Create a list of flagged terms before checking for definitions.
3. Verify definition mechanisms: For each flagged term, confirm that a definition mechanism exists and is reachable. Check for: inline definitions in surrounding text, a visible <dfn> element with associated <abbr title> or linked description, a glossary page linked from the content, or tooltip/expandable definitions. If the mechanism is a tooltip or expandable widget, proceed to step 4.
4. Keyboard navigation test: Using only the keyboard (Tab, Enter, Space, arrow keys), attempt to reach and activate every definition mechanism on the page. Verify that tooltips or expandable definitions can be triggered without a mouse. In Firefox with NVDA, navigate to defined terms and confirm that the definition is announced. In Safari with VoiceOver on macOS, use VO+Right to move through content and verify that definition context is available. In Chrome with JAWS, test that linked glossary entries receive focus and that link purpose is clear.
5. Screen reader reading order test: With NVDA in Firefox, activate Browse Mode and read through the page linearly. Confirm that when a jargon term appears, either the definition is read inline or the link/button to the definition is immediately adjacent and clearly labeled. Ensure the user is not required to navigate away from the page and lose context in order to access a definition.
6. Glossary completeness check: If the site uses a centralized glossary, cross-reference the list of flagged unusual terms against the glossary entries. Confirm every flagged term has a corresponding entry. Verify that the glossary page itself is accessible (proper heading structure, keyboard navigable, readable by screen readers).

How to Fix

Technical jargon without definition — Incorrect

<p>
  The system uses OAuth2 for authorization, issuing a JWT
  that expires after 3600 seconds. Refresh tokens are stored
  in an HttpOnly cookie to mitigate XSS vectors.
</p>

Technical jargon with inline definitions — Correct

<!-- Using dfn elements with title attributes and a linked glossary -->
<p>
  The system uses
  <dfn><abbr title='OAuth 2.0: An open authorization protocol that allows
  third-party applications to access user data without exposing
  credentials.'>OAuth2</abbr></dfn>
  for authorization, issuing a
  <dfn><abbr title='JWT (JSON Web Token): A compact, URL-safe token
  format used to transmit claims between parties.'>JWT</abbr></dfn>
  that expires after 3600 seconds. See our
  <a href='/glossary#security-terms'>Security Glossary</a>
  for full definitions.
</p>

Idiomatic language without explanation — Incorrect

<p>
  Our customer support team will go the extra mile to ensure
  your issue is resolved. We believe in burning the midnight
  oil so you never have to.
</p>

Idiomatic language rewritten in plain language — Correct

<!-- Plain language replacement is the most robust fix for idioms.
     If idioms must be retained for brand voice, provide a
     parenthetical explanation or tooltip. -->
<p>
  Our customer support team will make every effort to ensure
  your issue is resolved. We work extended hours so you
  receive help whenever you need it.
</p>

Medical or legal content with undefined specialized terms — Incorrect

<p>
  Patients diagnosed with dyslipidemia may be prescribed
  statins to manage LDL cholesterol levels and reduce the
  risk of atherosclerosis.
</p>

Medical content with accessible glossary links — Correct

<!-- Each technical term links to the relevant glossary anchor.
     The glossary page contains plain-language definitions. -->
<p>
  Patients diagnosed with
  <a href='/glossary#dyslipidemia'>dyslipidemia</a>
  (abnormal levels of lipids in the blood) may be prescribed
  <a href='/glossary#statins'>statins</a>
  to manage
  <a href='/glossary#ldl'>LDL cholesterol</a>
  levels and reduce the risk of
  <a href='/glossary#atherosclerosis'>atherosclerosis</a>
  (hardening and narrowing of the arteries).
</p>

Word used in a restricted or domain-specific sense — Incorrect

<p>
  Submit your token at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Restricted-sense word with contextual definition — Correct

<!-- The first use of the term in the restricted sense is
     marked with dfn and explained. Subsequent uses are clear
     by context. -->
<p>
  Submit your
  <dfn id='def-token'>token</dfn>
  (a single-use digital voucher issued when you complete
  a qualifying purchase) at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Common Mistakes

• Defining a term in the glossary but never linking to it from the content: A glossary is only useful if users know it exists and can reach it. Failing to link unusual terms to their definitions — or omitting a prominent glossary link in navigation — means many users will never discover the resource.
• Using <abbr title='...'> for full words rather than abbreviations: The title attribute on <abbr> is commonly misused as a general-purpose tooltip for any term. Screen readers handle title inconsistently, and it is invisible to keyboard users by default in most browsers. Use <dfn> with an accessible linked description or adjacent text for full words.
• Providing tooltip definitions that are not keyboard accessible: CSS-only or JavaScript tooltips that activate only on mouse hover exclude keyboard and touch users entirely. Any tooltip used to convey a definition must be triggerable via keyboard focus and must not disappear when the user moves focus inside it to read.
• Assuming industry-standard terms need no definition for a general audience: Terms like "bandwidth," "uptime," "SLA," or "API" may be obvious to technical teams but opaque to the general public visiting a telecom or cloud services website. Always assess terminology from the perspective of the least knowledgeable member of the intended audience.
• Defining a term only on its first occurrence in a document but not on pages where it appears without prior introduction: If a user enters the site on a deep-linked article page that references jargon defined only on a different page, they have no access to the definition. Each page must stand alone or provide navigation to the definition regardless of entry point.
• Using jargon inside form labels, button text, or error messages without definitions: Unusual words in interactive UI elements — such as "Authorize delegated access" on a button, or "Your session token is invalid" in an error message — are especially harmful because users need to understand these to complete critical tasks. These are frequently overlooked in content audits.
• Writing glossary definitions using additional jargon: A glossary entry that defines "amortization" as "the systematic allocation of an intangible asset's cost over its useful life" does not help a lay user. Definitions must themselves be written in plain language accessible to the intended audience.
• Ignoring language-specific idioms in multilingual or translated content: When content is translated from English into Turkish (or vice versa), idiomatic expressions are frequently translated literally, producing phrases that are nonsensical or confusing in the target language. Each localized version must be reviewed by a native speaker for idiomatic accuracy and comprehensibility.
• Treating <dfn> as purely semantic with no user-facing definition: The HTML <dfn> element marks the instance where a term is being defined, but it does not itself provide the definition to users. It must always be paired with either adjacent text, an aria-describedby association, or a visible definition in the surrounding paragraph.
• Omitting unusual words from automated audit checklists because no axe rule flags them: Because this criterion requires manual evaluation, it is easy to deprioritize during technical audits. Teams should establish a documented manual review process for language and terminology as a formal step in their accessibility QA workflow, not an afterthought.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility requirements aligned with WCAG 2.2 for a broad range of public and private entities operating in Turkey. The covered entities include public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

The circular mandates compliance with WCAG 2.2 Level AA as the baseline legal requirement. WCAG 3.1.3 — Unusual Words is a Level AAA criterion and is therefore not legally required under this regulation. However, this does not diminish its practical importance for Turkish organizations. Entities that serve linguistically diverse populations — including public health portals, national education platforms, and financial services companies — have strong ethical and reputational incentives to implement AAA criteria such as 3.1.3.

For certain specialized services, Level AAA conformance may effectively become necessary. Healthcare institutions serving patients with varying levels of health literacy, educational platforms operated under MoNE authorization that serve students with cognitive disabilities, and government portals required to communicate clearly with all citizens would benefit significantly from implementing this criterion. The Turkish disability rights framework, reinforced by Turkey's ratification of the UN Convention on the Rights of Persons with Disabilities, establishes a broader mandate for equal access to information that AAA criteria help fulfill in spirit even where they are not strictly mandated in law.

Organizations seeking to demonstrate best-in-class accessibility — whether for competitive advantage, international market access, public sector procurement eligibility, or genuine commitment to inclusive design — should treat WCAG 3.1.3 as part of a comprehensive accessibility program that extends beyond the regulatory minimum. Implementing a structured glossary system, training content authors to recognize and define unusual terminology, and incorporating language accessibility into editorial workflows are practical steps that serve Turkish users and align with the broader goals of Presidential Circular 2025/10.