Level AAA

Context-sensitive help (Level AAA) means help tied to the specific field or task the user is on -- not a link to a generic FAQ.

3.3.5 Help

In Plain Language

3.3.5 Help (Level AAA) requires that context-sensitive help is available for the field or task the user is currently working on[1]. The operative word is context-sensitive: a link to a generic FAQ, a global "Help" page, or a search box does not satisfy the criterion. The help has to be tied to the specific input the user is filling in -- the format the field expects, the meaning of a jargon term in the label, or an example of a valid value.

Delivery mechanism is flexible. Inline instructions below the field, a <details> disclosure with format guidance, a "What's this?" button that toggles a description, or a tooltip pointed to via aria-describedby all qualify. What does not qualify is placeholder text (see example below), a generic help-center link, or a tooltip that only appears on mouse hover with no keyboard equivalent.

3.3.5 is distinct from two nearby criteria. 3.3.2 Labels or Instructions (Level A) requires basic labels and instructions when content requires user input[2] -- it is the floor, not the ceiling. 3.3.2 / 3.2.6 Consistent Help (Level A, new in WCAG 2.2) requires that if a contact mechanism like a help link, phone number, or chat widget appears on multiple pages, it appears in the same relative order across them[3]. 3.3.5 goes further than both: it demands help that is about this field, right now.

Why It Matters

  • A field labelled "Country of habitual residence" on a visa application, or "MCC" on a merchant-services form, is unusable without an explanation of what the term means and how to choose a value. 3.3.5 forces that explanation next to the field, not in a separate help document the user has to search.
  • Help that is programmatically associated with the input via aria-describedby is announced by screen readers when the field receives focus. Help that sits as loose text above or below the input, with no association, is reachable by sighted users scanning the page but invisible to a screen-reader user tab-stopping through the form.
  • Users with cognitive and learning disabilities rely on persistent, co-located help to avoid re-reading instructions out of context. A help link that opens a new tab forces a working-memory hand-off back to the form -- the W3C COGA guidance on clear language and predictable instructions treats this as a core barrier for the audience 3.3.5 is designed to serve.
  • Experienced users hit the same wall on unfamiliar forms -- tax filings, government applications, clinical intake, technical configuration. Inline, field-level help is the difference between a form that is completable on the first attempt and one that generates a support ticket or abandonment.

Examples

Do: Provide inline help text associated with the input

Your 9-digit EIN in the format XX-XXXXXXX. Find it on your IRS notice or W-2 form.

✔ Help text is visible and programmatically linked via aria-describedby

<label for="ein">
  Employer Identification Number (EIN)
</label>
<input id="ein" type="text"
  aria-describedby="ein-help"
  placeholder="XX-XXXXXXX">
<p id="ein-help" class="help-text">
  Your 9-digit EIN in the format XX-XXXXXXX.
  Find it on your IRS notice or W-2 form.
</p>
Don't: Provide only a generic help page link
See help page

✘ No context-specific help -- user must leave the form to find guidance

<!-- FAILS: no context-sensitive help -->
<label for="ein">EIN</label>
<input id="ein" type="text">
<a href="/help">See help page</a>
<!-- User must navigate away to find what EIN means
     and what format is expected -->
Do: Use a help toggle that reveals field-specific instructions
The 9-digit number at the bottom-left of your check. It identifies your bank.

✔ Toggle reveals context-specific help -- aria-expanded and aria-controls manage state

<div class="field-group">
  <div class="field-header">
    <label for="routing">Routing Number</label>
    <button type="button"
      aria-expanded="false"
      aria-controls="routing-help">?</button>
  </div>
  <input id="routing" type="text"
    aria-describedby="routing-help">
  <div id="routing-help" hidden>
    The 9-digit number at the bottom-left of
    your check. It identifies your bank.
  </div>
</div>
Don't: Use placeholder text as the only help

✘ Placeholder disappears on focus -- help is lost when the user starts typing

<!-- FAILS: placeholder is the only help -->
<label for="routing">Routing Number</label>
<input id="routing" type="text"
  placeholder="Enter your 9-digit routing number">
<!-- Placeholder vanishes when user types,
     not announced reliably by screen readers -->

How to Fix It

  1. Pair every non-obvious field with persistent inline help. Put the explanation in a <p> or <span> with a unique id, then point the input at it with aria-describedby="that-id". The help is visible to sighted users and announced by screen readers on focus -- one piece of markup covers both.
  2. Use <details> or an aria-expanded toggle for longer explanations. When the help is a paragraph rather than a sentence (format rules, regulatory definitions, worked examples), collapse it behind a native <details> disclosure or a <button> with aria-expanded and aria-controls. Keep the target element linked via aria-describedby so screen readers pick it up even when collapsed.
  3. Show format examples as persistent text, not placeholder. For dates, phone numbers, identifiers, or codes, render the example ("e.g., 123-45-6789") in visible help text. Placeholder text disappears as soon as the user types, is styled at low contrast by default, and is announced inconsistently across screen readers -- it fails 3.3.5 and trips 1.4.3 and 1.3.1 as a bonus.
  4. Link directly to the relevant help section, not the help home page. If a field genuinely needs a longer article (a tax code lookup, a list of accepted document types), deep-link to the specific anchor. A "See help" link that drops the user on the help landing page to search for the right article is not context-sensitive and does not satisfy 3.3.5.
  5. Do not rely on hover-only tooltips. A tooltip that appears only on mouseover is invisible to keyboard and touch users. Trigger the same help on focus, make it dismissable, and keep it visible until the user moves away -- this is 1.4.13 Content on Hover or Focus territory and has to be satisfied alongside 3.3.5.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.5: Help. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/help.html ↩
  2. [2] W3C (2023). Understanding Success Criterion 3.3.2: Labels or Instructions. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ↩
  3. [3] W3C (2023). Understanding Success Criterion 3.2.6: Consistent Help. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html ↩