# Form field help only on a help page or on hover

Source: https://easeweb.dev/learn/field-help
Topics: Forms > Forms offer help beside the fields that need it (WCAG 3.3.5)
The fix: Put the help beside the field it is for. Either print it under the label and tie it to the field with aria-describedby, or put it in a details element straight after the field. A link beside the field to the help article about it also passes, but sends people away from the form to read it.
Test with: keyboard, screen reader, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/help.html https://www.w3.org/WAI/WCAG22/Techniques/general/G71 https://www.w3.org/WAI/WCAG22/Techniques/general/G89 https://www.w3.org/WAI/WCAG22/Techniques/general/G184 https://design-system.service.gov.uk/components/details/ https://inclusive-components.design/tooltips-toggletips/

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 clothes shop's returns page, Start a return, asks for two things: the order number and the email used for the order, then Find my order. The form is drawn clean, a label over each box and nothing else, and to the shop the first label is plain: every order has a number, and the number is on everything the shop sends.

A visitor wants to send back a scarf they bought three weeks ago. They know their email. The order number they have never needed: it might be on a slip in the parcel, which went out with the packaging, or in an email somewhere. Nothing on the form says where it is or what one looks like. The only help on the page is the Help link in the site's header, which opens the help centre's front page: a search box and a list of common questions. "Where is my order number?" is the third. It says the number is in the subject line of the order confirmation email and on the packing slip, and gives an example, HL-482130. To read it, the visitor has left the form, and the article's Start a return link takes them back to it empty.

A second build of the same form puts that answer in a small ? beside the label, shown in a dark box while the mouse pointer rests on it. With a mouse, the help is one hover away. Tab goes from the order number box to the email box and never stops on the ?, and a screen reader reads the field as "Order number, edit text", with nothing after it.

## Why it fails

Success criterion 3.3.5 Help is level AAA. It asks that context-sensitive help is available: W3C's Understanding page says such help lets people find out how to do something "without losing track of what they are doing", that people should be able to tell it exists, and that they should be able to get it "whenever they require it". It is needed only where the label doesn't say enough. "Order number" says what to enter, but not where to find it, and many shops answer that question in help centre articles of their own.

The header's Help link isn't help with this form. W3C's technique for a help link, G71, asks for a link on the page to help about filling in that page's form, or a link beside each field to help about that field. The help centre's front page is neither: getting the answer from it takes a search or a scan of the list, another page, and a way back to the form. The form gives no instructions at its start either, another of the techniques W3C lists for forms that ask for text (G184).

The ? puts the right words beside the field, but only for a resting mouse pointer. It is a `span`, which takes no keyboard focus; the CSS shows its text on `:hover` and nowhere else; and while its text is hidden with `visibility: hidden`, screen readers leave it out. To anyone using a keyboard or a screen reader, the field has no help, so they can't get it whenever they need it. W3C lists help in a `title` attribute only as an advisory technique for 3.3.5, not a sufficient one; [form field labels and hints only in a title tooltip](/learn/title-tooltips) shows why a tooltip of that kind fails the same people.

## Who is affected

The help matters most where a form asks for something people keep elsewhere: an order, account, policy or membership number, a reference from a letter, a code from an email. Those are also the forms people fill in when something has gone wrong, a return, a claim or a missed delivery, when patience is short. On a phone, leaving the form for the help centre means a new page on a small screen, and the way back is the browser's Back button or a link that starts the form again.

## What automation and AI miss

Each field has a label tied to it, and the Help link has a name, so axe, ANDI and every label check pass the form. Whether a field needs help depends on what people know and keep, and no rule can tell that. The EaseWeb audit hovers over the tooltips it finds to check how they behave (1.4.13). It also hovers over each small icon beside a form field that the keyboard can't reach and that holds hidden text, and when the hover shows that text and focus on the field doesn't, it sends it to a person as a lead: whether the field needs that help, and whether the page gives it some other way, takes a person to judge. A tooltip that a script adds to the page on hover isn't looked for. Nothing finds the help centre form of the failure, because no scan can tell that an article two pages away answers the form's question. Asked to add help to a field, a code assistant can reach for a tooltip on an icon, which is the second Before when the icon is a `span`.

## Before: the help only in the help centre

```html
<header>
  <a href="/">Hollis</a>
  <a href="/help">Help</a>
</header>
<main>
  <h1>Start a return</h1>
  <form method="post" action="/returns">
    <label for="order">Order number</label>
    <input id="order" name="order" type="text">

    <label for="email">Email used for the order</label>
    <input id="email" name="email" type="email" autocomplete="email">

    <button type="submit">Find my order</button>
  </form>
</main>
```

```css
form {
  display: grid;
  gap: 0.5rem;
  max-width: 24rem;
}
```

- Nothing beside Order number says where to find it or what one looks like.
- The only help is the Help link in the header, which opens the help centre's front page.
- Reading the answer there means leaving the form.

## Before: the help in a ? that a hover shows

```html
<header>
  <a href="/">Hollis</a>
  <a href="/help">Help</a>
</header>
<main>
  <h1>Start a return</h1>
  <form method="post" action="/returns">
    <div class="label-row">
      <label for="order">Order number</label>
      <span class="tip">
        ?
        <span class="tip-text">It's in the subject line of your order confirmation email, and on your packing slip, for example HL-482130.</span>
      </span>
    </div>
    <input id="order" name="order" type="text">

    <label for="email">Email used for the order</label>
    <input id="email" name="email" type="email" autocomplete="email">

    <button type="submit">Find my order</button>
  </form>
</main>
```

```css
form {
  display: grid;
  gap: 0.5rem;
  max-width: 24rem;
}

.label-row {
  display: flex;
  gap: 0.5rem;
}
.tip {
  position: relative;
}
.tip-text {
  visibility: hidden;
  position: absolute;
  width: 16rem;
}
.tip:hover .tip-text {
  visibility: visible;
}
```

- The ? is a `span`, so Tab never stops on it.
- Only `:hover` shows its text, and a keyboard has no way to hover.
- While hidden, the text is left out of what a screen reader reads, so the field is read with no help.
- Without a mouse, the Help link in the header is still the only help.

## After: a hint under the label

```html
<header>
  <a href="/">Hollis</a>
  <a href="/help">Help</a>
</header>
<main>
  <h1>Start a return</h1>
  <form method="post" action="/returns">
    <label for="order">Order number</label>
    <p id="order-hint" class="hint">It's in the subject line of your order confirmation email, and on your packing slip, for example HL-482130.</p>
    <input id="order" name="order" type="text" aria-describedby="order-hint">

    <label for="email">Email used for the order</label>
    <input id="email" name="email" type="email" autocomplete="email">

    <button type="submit">Find my order</button>
  </form>
</main>
```

```css
form {
  display: grid;
  gap: 0.5rem;
  max-width: 24rem;
}

.hint {
  margin: 0;
  color: #4a5560;
}
```

1. Print the help under the label, in the words of the help centre's answer: where the number is, and what one looks like.
2. Tie it to the field with `aria-describedby`, so a screen reader reads it after the field's name and role.
3. Take out the ?, if there was one: the help is on screen for everyone now.

This fixes both Befores and passes 3.3.5. The hint is in the shop's grey, #4a5560, at 7.61:1 on white. Keep it to a line or two: a screen reader reads all of it each time focus lands on the field.

## After: a details element under the field

```html
<header>
  <a href="/">Hollis</a>
  <a href="/help">Help</a>
</header>
<main>
  <h1>Start a return</h1>
  <form method="post" action="/returns">
    <label for="order">Order number</label>
    <input id="order" name="order" type="text">
    <details>
      <summary>Where do I find my order number?</summary>
      <p>It's in the subject line of your order confirmation email, and on your packing slip, for example HL-482130.</p>
      <p>Can't find the email? Search your inbox for "Hollis order".</p>
    </details>

    <label for="email">Email used for the order</label>
    <input id="email" name="email" type="email" autocomplete="email">

    <button type="submit">Find my order</button>
  </form>
</main>
```

```css
form {
  display: grid;
  gap: 0.5rem;
  max-width: 24rem;
}

summary {
  cursor: pointer;
  text-decoration: underline;
}
```

1. Put the help in a `details` element straight after the field, with the question people ask as its `summary`.
2. Leave it closed. People who know their number Tab past it; people who don't open it with Enter or Space, or a click.
3. Let the browser do the rest: it opens and closes the help and tells screen readers whether it is open, with no script and no ARIA.

This fixes both Befores and passes 3.3.5. It suits help longer than a line that most people won't need, such as a picture of where the number is printed, or what to do without the email. GOV.UK's guidance for the same element is not to put information most people need inside it.

## After: a link beside the field to the help about it

```html
<header>
  <a href="/">Hollis</a>
  <a href="/help">Help</a>
</header>
<main>
  <h1>Start a return</h1>
  <form method="post" action="/returns">
    <label for="order">Order number</label>
    <input id="order" name="order" type="text">
    <a href="/help/order-number" target="_blank">Where do I find my order number? (opens in a new tab)</a>

    <label for="email">Email used for the order</label>
    <input id="email" name="email" type="email" autocomplete="email">

    <button type="submit">Find my order</button>
  </form>
</main>
```

```css
form {
  display: grid;
  gap: 0.5rem;
  max-width: 24rem;
}
```

1. Link straight to the help centre's answer about the order number, not to the help centre's front page.
2. Put the link right after the field, so it is next in Tab order.
3. Open it in a new tab, and say so in the link's words, so the form and what has been typed into it stay where they were.

This is the smallest change: the answer already exists, and the form gains one link. It fixes both Befores once the ? gives way to the link, and passes 3.3.5 with W3C's help-link technique, G71. It is not enough on its own: people leave the form for another tab, read a whole article for one line, and carry the answer back to the form in their head. See [links that open a new tab without saying so](/learn/new-tab-links) for why the link says where it opens.

## Which option to use

All three pass 3.3.5. Use the hint when the help is a line or two, as here: it is on screen with nothing to open, and read with the field. Use the details element when the help is longer, or only some people need it, so the form stays short for everyone else. Use the link only when the help can't be cut down to fit the form, such as a long article other pages link to as well, and print the one line people need beside the field too when you can.

## Implementation decisions

If the design keeps a ? beside the label, make it a button that opens the help and closes it again, never a `span` that shows it on hover. [Tooltips that vanish on approach and can't be dismissed](/learn/hover-content) builds one as a toggletip. Each such button is a stop of its own in the Tab order, and people hear the help only if they open it, so for help most people may need, a hint printed on screen is simpler.

Accept the order number the way people copy it: with or without HL-, a #, or spaces. Then the example in the help shows what to look for, not a rule to follow. When a field does accept only one format, say so on screen, in the label or the hint: that is 3.3.2 Labels or Instructions, at level A, and [form field labels and hints only in a title tooltip](/learn/title-tooltips) covers it.

Write the help once and use it in both places. When the hint and the help centre's answer come from the same piece of content, they stay in step when the confirmation email or the order number changes.

A placeholder is no place for help. It disappears as soon as people start typing, which is when they want to compare what they typed with the example. When the number isn't found, the error message beside the field can say again where to look; see [form errors that don't say how to fix them](/learn/accessible-form-errors).

The site's own Help link still matters for everything the form doesn't answer. Keep it in the same place on every page, as [help links that move from page to page](/learn/consistent-help) explains.

## Verify the fix

1. Fill in the form as someone new to the site would, from your own emails and papers, and list every field where you would leave the page or stop to look something up. Confirm each one has help beside it that says where to find the value, or how to work it out.
2. Put the mouse aside and fill in the form with the keyboard alone. Confirm every piece of help is on screen, or opens with Enter or Space from a control that Tab reaches straight after its field.
3. With a screen reader, Tab to each field that has help. Confirm a hint is read with the field, or that the next Tab reaches the control that opens the help, and that it says whether it is open.
4. On a phone and at 400% zoom, confirm the help shows under or right after its field, not off to one side or in a box that covers the field.

Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat when fields are added, and when what people are asked for, such as the order number's format, changes.

## Limits

This is a starting pattern, not a guarantee for every application. 3.3.5 is level AAA, beyond the A and AA levels that EN 301 549 and Section 508 require, but W3C's Understanding page names the people such help serves: people with writing, reading and intellectual disabilities, and older people who find typing hard. This guide covers help with one field: not the label itself ([vague form labels that don't say what to enter](/learn/descriptive-labels)), not how a tooltip behaves once it opens ([tooltips that vanish on approach and can't be dismissed](/learn/hover-content)), and not where the site's help link sits from page to page ([help links that move from page to page](/learn/consistent-help)). Which fields need help depends on the people who fill in the form and what they have to hand, so test it with them.

## What screen readers do (tested by hand by EaseWeb)

`aria-describedby`: Gives an element a description, such as a hint or an error, from text elsewhere on the page.

| Screen reader | Browser and system | Tab to it | Down Arrow |
| --- | --- | --- | --- |
| JAWS | Chrome, Windows 11 | Not tested | Not tested |
| NVDA | Chrome, Windows 11 | Not tested | Not tested |
| JAWS | Edge, Windows 11 | Not tested | Not tested |
| NVDA | Firefox, Windows 11 | Not tested | Not tested |
| NVDA | Edge, Windows 11 | Not tested | Not tested |
| JAWS | Firefox, Windows 11 | Not tested | Not tested |
| VoiceOver | Safari, macOS | Not tested | Not tested |
| VoiceOver | Safari, iOS | Not tested | Not tested |
| TalkBack | Chrome, Android | Not tested | Not tested |

https://easeweb.dev/learn/screen-reader-support

---

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