# Abbreviations and acronyms that are never spelled out

Source: https://easeweb.dev/learn/abbreviations
Topics: Words and reading > Abbreviations are expanded (WCAG 3.1.4)
The fix: Either write the expansion beside the first use of each abbreviation, as in "Active noise cancellation (ANC)", or make the letters a link to their definition on the same page or in a glossary. A title on an abbr element is not enough on its own: it shows only as a tooltip under a mouse pointer, and most screen readers don't read it.
Test with: screen reader, keyboard, touch
References: https://www.w3.org/WAI/WCAG22/Understanding/abbreviations.html https://www.w3.org/WAI/WCAG22/Techniques/general/G102 https://www.w3.org/WAI/WCAG22/Techniques/general/G97 https://www.w3.org/WAI/WCAG22/Techniques/general/G55 https://www.w3.org/WAI/WCAG22/Techniques/general/G62 https://www.w3.org/WAI/WCAG22/Techniques/html/H28 https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-abbr-element https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute https://www.powermapper.com/tests/screen-readers/labelling/acronym-abbr-title/ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/abbr https://soundcore.com/blogs/open-ear/anc-vs-enc https://www.slashgear.com/1988625/anc-vs-enc-noise-cancellation-pros-cons

This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.

## What happens

An online shop sells a pair of wireless earbuds. Under the product name, a row of chips lists what they do: "ANC", "ENC" and "30 hours with the case". The people who wrote the page use these letters every day, and so do the audio sites they read.

A buyer who wants a quiet train ride needs to know which of the two that is. ANC stands for active noise cancellation: microphones pick up the noise around you, and the earbuds play a sound that cancels it. ENC stands for environmental noise cancellation, a feature for calls: it filters the noise around you out of your microphone, so the person you call hears you more clearly, and it changes nothing you hear. The page says neither. A buyer comparing these earbuds with a cheaper pair that lists only ENC can't tell what the extra money buys.

## Why it fails

Success Criterion 3.1.4, Abbreviations, is Level AAA. It asks for a mechanism for identifying the expanded form or meaning of abbreviations. Its Understanding document exempts an abbreviation that has become part of the language, such as laser, which a common dictionary lists as a word, and well-known names such as IBM; beyond that, it doesn't exempt abbreviations, even common or familiar ones. ANC and ENC are neither words nor a company's name, so they need an expansion, and the page gives none: nothing beside the letters, no link from them, and no glossary.

W3C's sufficient techniques show where the expansion goes: in the text right before or after the first use (G97), behind a link from the abbreviation to its definition (G55), or in a glossary (G62). Nothing in HTML expands letters by itself. A browser draws ANC as written, and a screen reader reads it as written, so the expansion reaches people only when the page writes it.

## Who is affected

An abbreviation is a shortcut for people who already know it. Earbuds are bought by everyone, not only by people who read audio reviews, and the two features that matter most, for a commute and for calls, differ here by one letter.

## What automation and AI miss

No axe rule checks 3.1.4. EaseWeb's audit sends a review lead, `ew:abbreviation-manual-check`, for a page whose main content uses letters such as ANC that it never expands beside a use, never turns into a link and never defines in a `dt` or `dfn`, and lists apart the ones expanded only in an `abbr` title. It stays a lead, because whether the letters have become a word in their own right, or are a company's name, is a judgement. An AI assistant asked to fix the page may wrap each abbreviation in `abbr` with a `title`. The markup looks right and passes a code review, but the expansion then shows only as a tooltip under a mouse pointer, and most screen readers don't read it (see "Implementation decisions").

## Before: abbreviations with no expansion

```html
<h1>Drift wireless earbuds</h1>
<ul class="features">
  <li>ANC</li>
  <li>ENC</li>
  <li>30 hours with the case</li>
</ul>
…
```

- ANC and ENC are never spelled out, beside the letters or anywhere else on the page.
- Nothing links them to a definition, and the page has no glossary.
- The two differ by one letter, so a buyer can't tell which one makes the train quieter.

## After: the expansion beside the first use

```html
<h1>Drift wireless earbuds</h1>
<ul class="features">
  <li>Active noise cancellation (ANC)</li>
  <li>Environmental noise cancellation (ENC) for calls</li>
  <li>30 hours with the case</li>
</ul>
…
```

1. Write each abbreviation's expansion in the text, with the letters after it in parentheses, as W3C technique G97 describes. Everyone who reads the list reads what ANC and ENC stand for.
2. Where the expansion alone doesn't say what the feature does, add the few words that do: "for calls" tells a buyer that ENC is about their voice, not about the noise they hear.
3. Give the expansion the first time the letters appear on the page. Later uses on the same page, such as "ANC on" in the specs, can stand alone.

This fixes the Before and passes 3.1.4. The expansion is part of the text, so it reaches every browser, screen reader and translation tool, and every device. The cost is length: a chip of three letters becomes a phrase, and the row of chips takes more lines.

## After: each abbreviation linked to its definition

```html
<h1>Drift wireless earbuds</h1>
<ul class="features">
  <li>
    <a href="#spec-anc">ANC</a>
  </li>
  <li>
    <a href="#spec-enc">ENC</a>
  </li>
  <li>30 hours with the case</li>
</ul>
…
<h2>Features explained</h2>
<dl>
  <dt id="spec-anc">ANC</dt>
  <dd>Active noise cancellation: microphones pick up the noise around you, and the earbuds play a sound that cancels it, so a train sounds quieter.</dd>
  <dt id="spec-enc">ENC</dt>
  <dd>Environmental noise cancellation: during a call, the microphones filter the noise around you out of your voice, so the person you call hears you clearly. It doesn't make anything quieter for you.</dd>
</dl>
```

1. Add a "Features explained" section to the page, with each abbreviation as a term in a `dl` and its definition in the `dd` after it, as a glossary does (W3C technique G62).
2. Start each definition with the expansion, then say what the feature does for the buyer.
3. Give each term an `id`, and make the letters in the feature list a link to it (G55), underlined like the shop's other links so readers can see that it leads somewhere. Following the link with a click, a tap or Enter brings the definition into view.

This fixes the Before and passes 3.1.4. The chips keep their short look, and the definition has room for more than the expansion. The cost is a step: the reader has to see that the letters are a link, follow it and find their way back, and the definition sits away from where they were reading.

## Which option to use

Both pass. Spell an abbreviation out beside it when the expansion says enough, as active noise cancellation does: it costs a few words, and nobody has to do anything to read it. Link to a definition when the letters need more than their expansion to make sense, as ENC does, or when the design has no room for the long form in the row itself, and draw the link so it looks like one. A long spec sheet can do both: spell each abbreviation out at its first use, and link the later uses to the definitions.

## Implementation decisions

An `abbr` element with a `title`, as in `<abbr title="Active noise cancellation">ANC</abbr>`, is not enough on its own. Browsers draw a dotted underline under it and show the title as a tooltip once a mouse pointer rests on the letters. The element can't take focus, so a keyboard never brings the tooltip up, and a touch screen never shows it. The HTML standard says that relying on the `title` attribute is currently discouraged, for these reasons. In PowerMapper's screen reader tests, last updated in December 2025, VoiceOver on macOS and iOS ignored the title, NVDA didn't read it while reading on through the text, and JAWS with its default settings read it only in Chrome. W3C now lists H28, the `abbr` technique, as advisory rather than sufficient. Use an `abbr` title, if at all, on top of an expansion in the text. Labels and hints kept in a title have the same problem: see [form field labels and hints only in a title tooltip](/learn/title-tooltips).

An `abbr` with no title, the other form this failure takes, adds nothing a reader sees or hears. The HTML standard allows it as a hook for styling, such as small capitals, but it is not an expansion.

When the same letters stand for different things in different places on one page, a single expansion at the first use is wrong for the rest. For that case, W3C's sufficient technique links every use to its own definition (G55).

On a Japanese page, write the expansion in Japanese, with full-width parentheses: アクティブノイズキャンセリング（ANC）. English letters are common on Japanese shops too, often run into a word (ANC搭載), and an English expansion helps a Japanese reader no more than the letters do.

Units are abbreviations too. A battery listed in mAh, or a weight in lb, as in W3C's own H28 example, can be spelled out in the spec table's row header at the first use, such as "Battery capacity (milliampere-hours, mAh)".

## Verify the fix

1. Read each page as someone new to the subject, and list every abbreviation in the text, headings, chips, buttons and tables. Leave out those that have become words, such as laser, and companies' names.
2. For each one, check that its expansion is written beside its first use on the page, or that the letters link to a definition that gives it.
3. On a phone, and then with the keyboard alone, reach the expansion of each abbreviation: it is on the screen or one link away, never only in a tooltip.
4. With a screen reader, read the feature list and follow each link to a definition, and check that the expansion is read.

Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever the copy changes.

## Limits

This is a starting pattern, not a guarantee. The example is one product page with two abbreviations. 3.1.4 is Level AAA, above the AA level that most policies ask for, but spelling the letters out costs a few words and tells a buyer what they are paying for. The criterion asks for the expansion or meaning, not that the reader understand it: when the expansion is itself a term the reader may not know, as environmental noise cancellation may be, see [jargon and unusual words with no definition](/learn/jargon). Speech engines and screen readers change between releases, so no particular spoken result is claimed here.

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)
