Abbreviation & Acronym Expander

Flag every unexpanded acronym in pasted copy (WCAG 3.1.4)

Scans pasted text for capitalised acronyms that are never defined in parentheses on first use, flagging each as a potential WCAG 3.1.4 (Abbreviations) issue. Includes a bundled list of common expansions (NHS, GDPR, URL, API) for auto-suggestion. Built for technical writers and accessibility editors. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What does WCAG 3.1.4 (Abbreviations) require?

It requires a mechanism to find the expanded form or meaning of abbreviations. The simplest way to satisfy it in body text is to spell out the full term on first use with the acronym in parentheses, for example 'Application Programming Interface (API)'.

The Abbreviation & Acronym Expander scans your copy for capitalised acronyms that are never defined on first use and flags each one as a potential WCAG 2.1 3.1.4 (Abbreviations) issue. The criterion asks for a mechanism to find the expanded form of an abbreviation; in plain body text the standard approach is to spell out the full term the first time it appears, with the acronym in parentheses. This tool finds the acronyms you forgot to define.

Who this is for

Technical writers, accessibility editors, content reviewers, and developers working on public-sector sites (where WCAG AA compliance is a legal requirement under the Public Sector Bodies Accessibility Regulations in the UK and equivalent legislation elsewhere) all benefit from a systematic acronym audit. The tool is also useful for anyone publishing to a mixed audience — a government leaflet full of undefined acronyms can be genuinely opaque to readers who are not domain insiders.

How it works

  1. Detection. The tool tokenises your text and identifies acronyms — runs of two or more capital letters, optionally mixed with digits, such as API, GDPR, H2O, or PDF417.
  2. First-use check. For each distinct acronym it looks at the first occurrence and checks whether an expansion appears alongside it. Two patterns satisfy the rule: the acronym followed by its expansion in parentheses — API (Application Programming Interface) — or the expansion followed by the acronym in parentheses — Application Programming Interface (API).
  3. Suggestion. If no expansion is present, the acronym is flagged. Where the term is in the bundled dictionary (NHS, GDPR, URL, API, HTML, and dozens more), a suggested expansion is shown so you can paste it straight in.

What WCAG 3.1.4 actually requires

The criterion (Level AAA in WCAG 2.1) says a mechanism must exist for readers to find the expanded form. In practice there are three common ways to satisfy it:

  • Inline first-use expansion — “General Data Protection Regulation (GDPR)” on first mention, then “GDPR” thereafter.
  • HTML abbr elementGDPR wraps the term with the full form in the title attribute, accessible to screen readers.
  • Glossary page — a linked glossary defining all abbreviations used in the document.

This tool checks for the first method, which is the most portable and the most readable without assistive technology.

Tips and notes

  • Define each acronym once, on its first appearance, then use the short form freely for the rest of the document.
  • Very common terms like UK, US, OK, and AM/PM are excluded from flagging because spelling them out adds noise rather than clarity; adjust this judgement to your specific audience.
  • For acronyms that repeat frequently across a long page, an HTML abbr element adds programmatic accessibility on top of the inline expansion and satisfies the criterion even if the reader jumps into the middle of the page.
  • Re-paste the edited text after adding definitions to confirm the warnings clear — the tool re-scans on each paste.