# Jargon and unusual words with no definition

Source: https://easeweb.dev/learn/jargon
Topics: Words and reading > Jargon and unusual words are explained (WCAG 3.1.3)
The fix: Either define the term in the sentence where it is used, or put a disclosure that asks the reader's question (What is the excess?) straight under it, or link the term to its entry in a glossary. All three pass; the definition in the sentence is the one every reader meets without having to ask.
Test with: keyboard, touch, screen reader
References: https://www.w3.org/WAI/WCAG22/Understanding/unusual-words.html https://www.w3.org/WAI/WCAG22/Techniques/general/G101 https://www.w3.org/WAI/WCAG22/Techniques/general/G112 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/H40 https://www.w3.org/TR/coga-usable/#use-clear-words-pattern https://www.w3.org/TR/coga-usable/#use-literal-language-pattern https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute

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

A car rental site's booking has an Extras step. Under the heading Protection, it says "Excess: 1,000.00 for each accident", and offers a checkbox: "Excess cover, 12.00 a day". To anyone who works with insurance, that is a complete offer. If the car is damaged, the hirer pays up to 1,000.00 towards the repair for each accident and the insurance pays the rest, and excess cover brings what they pay down to nothing.

To someone hiring a car for the first time, excess is an everyday word for too much of something. They may take the 1,000.00 for a deposit held on their card, or for the most the insurance will pay out, and excess cover for an extra fee they can skip. Nothing on the page, or anywhere on the site, says which. They decide on 12.00 a day without knowing that it settles whether one scrape costs them nothing or 1,000.00.

## Why it fails

Success criterion 3.1.3, Unusual Words, is Level AAA. It asks for a mechanism to find the specific definition of words or phrases used in an unusual or restricted way, including idioms and jargon. WCAG defines jargon as words used in a particular way by people in a particular field, and excess is exactly that: in insurance it is the part of each claim the customer pays, a meaning the everyday word doesn't give. Its Understanding document lets authors count on readers using context, and on a specialist audience knowing its own words, but it encourages meeting the criterion for specialised information written for non-specialists, which is what a booking page for the public is.

The page gives no definition: not in the sentence, not under it, not behind a link, not in a glossary that can be found from the site. A paragraph carries only the words the author wrote, so there is no meaning for a browser, a screen reader or a reading tool to pass on either. The reader has the word, the number and a checkbox, and has to bring the insurance meaning with them.

## Who is affected

The word sits on the line that decides what an accident will cost, so a wrong guess costs money, not only a moment's doubt: someone who takes the 1,000.00 for a refundable deposit, or excess cover for an optional fee, turns the cover down for the wrong reason. The same happens with any trade word in a sign-up or checkout flow, such as "prorated" on a plan change, "pre-authorisation" on a card payment or "sum insured" on a policy.

## What automation and AI miss

Nothing in the markup is wrong, so no automated check finds it: axe and the other rule sets used for audits have no rule for 3.1.3, and EaseWeb's audit has no check for it. Whether a word is used in a narrow sense depends on the field, the audience and the sentence, and code can't tell that. An AI assistant asked to review the page sees a paragraph and a labelled checkbox. Asked about the wording, it may well know what an excess is and see nothing missing, which is the blind spot of every expert reader, the writer included. Readability scores don't find it either: "Excess: 1,000.00 for each accident" is a short line of common words.

## Before: a trade term with no definition

```html
<h2>Protection</h2>
<p>
  Excess: 1,000.00 for each accident
</p>
<label>
  <input type="checkbox" name="excess-cover">
  Excess cover, 12.00 a day
</label>
```

- In insurance, excess means the most the hirer pays towards damage in each accident, a meaning the everyday word doesn't give.
- Nothing on the page, or on the site, says what it means, and the offer of excess cover depends on it.

## After: define the term where it is used

```html
<h2>Protection</h2>
<p>
  Excess: 1,000.00 for each accident. This is the most you pay towards damage to the car; the insurance pays the rest.
</p>
<label>
  <input type="checkbox" name="excess-cover">
  Excess cover, 12.00 a day: you pay nothing towards damage
</label>
```

1. Write the meaning straight after the term, in the same paragraph and in everyday words: the most you pay towards damage to the car, with the insurance paying the rest. This is W3C technique G112, an inline definition.
2. Say in the checkbox's label what excess cover does for the reader: they pay nothing towards damage. The label is the checkbox's name, so a screen reader reads the meaning with it.

This fixes the Before and passes 3.1.3. Every reader meets the meaning together with the word, without having to know that there is anything to look up, and it reaches every browser, screen reader and translation tool as part of the text. It costs one sentence on the page.

## After: a disclosure under the term

```html
<h2>Protection</h2>
<p>
  Excess: 1,000.00 for each accident
</p>
<details>
  <summary>What is the excess?</summary>
  <p>
    The most you pay towards damage to the car in each accident. The insurance pays the rest. With excess cover, you pay nothing.
  </p>
</details>
<label>
  <input type="checkbox" name="excess-cover">
  Excess cover, 12.00 a day
</label>
```

1. Put a `details` element straight after the line, with a `summary` that asks the reader's own question: "What is the excess?"
2. Write the meaning inside it, in everyday words, together with what excess cover changes. It stays closed until someone opens it, with a click, a tap, or Enter or Space on the summary.

This fixes the Before and passes 3.1.3: the definition is on the page beside the term, and any input opens it. Browsers expose the summary as a control that is expanded or collapsed, most screen readers say which, and they read the meaning once it is open. The line stays short, but a reader who thinks they already know the word has no reason to open it.

## After: link the term to the glossary

```html
<h2>Protection</h2>
<p>
  <a href="#excess">Excess</a>: 1,000.00 for each accident
</p>
<label>
  <input type="checkbox" name="excess-cover">
  Excess cover, 12.00 a day
</label>
<h2>Rental words</h2>
<dl>
  <dt>Deposit</dt>
  <dd>Money held on your card while you have the car, and given back when you return it.</dd>
  <dt id="excess">Excess</dt>
  <dd>The most you pay towards damage to the car in each accident. The insurance pays the rest. With excess cover, you pay nothing.</dd>
</dl>
```

1. Make the term a link to its entry in a glossary, as W3C technique G55 describes. The link's text is the term itself, so it says what it leads to.
2. Write the glossary as a description list, each term in a `dt` and its meaning in the `dd` after it, as technique H40 does, and give each `dt` an `id`: `<dt id="excess">Excess</dt>`. The link then lands on the entry, and the entry for excess also says what excess cover changes.
3. Put the glossary at the foot of the booking step, so the reader reads the entry and goes straight back up to the choice. Where the same words appear on many pages, one glossary page can serve them all (`href="/help/words#excess"`); open it in the same tab, and keep the booking's choices for when the reader comes back.

This fixes the Before and passes 3.1.3, and one glossary serves every term on the step. It sends the reader away from the line to read one entry, and, like the disclosure, it is found only by readers who know they need it.

## Which option to use

All three pass. Define the term in the sentence: it is the one way that reaches readers who don't know the word is a term at all, and it costs one sentence and no code. Use the disclosure when the definition is long, or when a page has many such words and printing every definition would bury what people came to do. Link to a glossary when the same terms appear on many pages, or when the full meaning needs examples and exceptions; where a decision on the page depends on the word, give the short meaning in the sentence as well.

## Implementation decisions

Finding the words is the work. Read the page as the least experienced customer it serves, and look for three kinds: words of a trade (excess, prorated, pre-authorisation), everyday words given a narrow meaning in this field, and words the company made up, such as the name of a plan or a feature. The Understanding document says plainly that new and invented words are not exempt.

Idioms are the other form the failure takes: "a ballpark figure", "out of pocket", "we'll circle back". Where you can, rewrite them in literal words, so there is nothing left to define. Where a phrase has to stay, such as in a slogan, the same three fixes apply.

Write a definition in words simpler than the term: "the most you pay towards damage", not "the deductible amount", which is another term. Say what it means for the reader in this case, with the page's own number where there is one. Then use the same word for the same thing everywhere: a site that says excess on the booking and deductible in the confirmation email has two words to define, and readers will take them for two things.

Don't put the definition only in a `title` attribute or in a tooltip that opens on hover. It shows only to a mouse resting on the word, never on a touch screen or to a keyboard; see [form field labels and hints only in a title tooltip](/learn/title-tooltips), which fails the same way. A `dfn` element around the term (technique H54) marks the place where it is defined, but it is not a definition: the meaning still has to be written beside it.

An abbreviation such as CDW, a collision damage waiver, is a different failure: see [abbreviations and acronyms that are never spelled out](/learn/abbreviations). When the whole text is hard, not one word, as in a long rental agreement, see [terms and policies with no plain-language summary](/learn/reading-level).

## Verify the fix

1. Read each page as someone doing this for the first time, and list every word or phrase whose meaning here is not its everyday one, or that only people in the trade use, idioms and invented names included.
2. For each one, check that a definition is at hand where it is used: in the same sentence or the next one, in a disclosure beside it, or behind a link from the word itself.
3. Read each definition: it uses everyday words, not another term, and says what the term means for the reader.
4. With only a keyboard, then on a phone, then with a screen reader, reach each definition from its term and read it.

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 word on one booking step. 3.1.3 is Level AAA, above the AA level that most policies ask for, but a definition costs a sentence, and on a booking or checkout page it decides whether people know what they are paying for. Which words need defining depends on who reads the page, so a page for specialists can define fewer than a page for the public. Definitions don't make a hard text easy: they help with single words, and a page full of them needs rewriting more than it needs a glossary.

---

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