WCAG 3.3.5: Help
A label tells you a field is called “Policy number.” It does not tell you where on earth to find your policy number. This criterion fills that gap: wherever users must provide input, help specific to that task must be available — field instructions, examples, help links, or an assistant — right where the confusion happens.
The success criterion, in full
Context-sensitive help is available.
Three words, but with precise scope: it applies to content that requires user input, and “context-sensitive” means the help addresses the specific function being performed — not a generic support portal. If a form is so simple that its labels are all the help anyone needs, that already satisfies the criterion.
Who this helps
People with cognitive and learning disabilities
An ambiguous field is a wall, not a puzzle. Inline explanations and examples remove the inference step — the difference between completing a benefits application and abandoning it.
People with memory impairments
Requests for identifiers — account numbers, reference codes, previous addresses — assume recall. Help that says where to find the information replaces memory with a procedure.
People with anxiety, and first-time users
Forms with legal or financial weight are frightening when a question is unclear. Knowing help is one keystroke away lowers the stakes of every field.
Screen reader users
Sighted users skim the whole page for clues; screen reader users hear the form linearly. Help programmatically associated with each field (aria-describedby) arrives exactly when the field does.
The business case writes itself: every field a user cannot answer is a support ticket, a phone call, or an abandoned conversion. Context help is one of the few accessibility measures with an immediately measurable completion-rate payoff.
What the requirement covers
The criterion applies when content requires user input. Any of these forms of help can satisfy it — choose per field or per form, matching the difficulty of the question:
Field-level instructions
Persistent hint text with the field: what the value is, where to find it, what format it takes. The workhorse technique — no interaction required.
Examples of expected input
“e.g. AB-1234567” or a completed sample row. Examples communicate format faster than any description, especially across languages.
Help links
A link beside the field or form leading to task-specific help — “Where is my policy number?” — provided consistently so users learn to expect it.
Assistants and spell checking
A human chat, a well-built automated assistant scoped to the task, or spell checking with suggestions for free-text input all count as help mechanisms.
Two boundary notes. First, if labels alone genuinely suffice (a two-field newsletter signup), the criterion is met without extra apparatus. Second, don’t confuse this with WCAG 2.2’s 3.2.6 Consistent Help (A), which requires help mechanisms you already offer to appear in a consistent place across pages — 3.3.5 requires the help to exist and be context-specific.
Pass and fail examples
✓ Passes 3.3.5
- A tax form where every unfamiliar field has hint text plus a “Where do I find this?” link with a screenshot of the source document.
- An insurance claim with an “Example claim” the user can view at any point, and a live-chat assistant.
- A date field showing its expected format and an example: “Date of birth (DD/MM/YYYY), e.g. 04/07/1990”.
- A simple contact form whose labels (“Name”, “Email”, “Message”) are all the help anyone could need.
✗ Fails 3.3.5
- A government application asking for a “Form 27B/6 reference number” with no explanation of what that is or where it lives.
- A checkout whose only “help” is a footer link to a generic FAQ homepage unrelated to the checkout task.
- Help text hidden in a tooltip that only appears on mouse hover — unreachable by keyboard and touch (also fails 1.4.13).
- A complex eligibility questionnaire where wrong interpretations have legal consequences, offered with no guidance at all.
Code: accessible help patterns
Persistent hint text, programmatically associated
Connect the help to the field with aria-describedby so screen readers announce it when the field gets focus. Visible, persistent text beats any disclosure widget.
<label for="policy">Policy number</label>
<input id="policy" type="text" inputmode="numeric"
aria-describedby="policy-help" autocomplete="off" />
<p id="policy-help" class="hint">
10 digits, printed in the top-right corner of your policy
documents and renewal letters. Example: 4402318876.
</p>A keyboard-accessible help disclosure
When the explanation is too long to sit inline, use a real button and a disclosure region — never a hover-only tooltip. This stays operable by keyboard, touch, and voice control.
<label for="utr">Unique Taxpayer Reference (UTR)</label>
<input id="utr" type="text" aria-describedby="utr-help" />
<button type="button" aria-expanded="false" aria-controls="utr-help"
onclick="toggleHelp(this)">
Help: where to find your UTR
</button>
<div id="utr-help" hidden>
<p>Your UTR is a 10-digit number on letters from the tax
office about your Self Assessment, and in your online
tax account under "Profile".</p>
<p><a href="/help/find-utr">Full guide with pictures</a></p>
</div>A form-level help link, placed consistently
<form aria-labelledby="claim-heading">
<h2 id="claim-heading">Submit an expense claim</h2>
<p>
<a href="/help/expense-claims">
Help with this form: allowed expenses, receipts, and deadlines
</a>
</p>
<!-- fields … -->
</form>Common failures
- Requesting obscure identifiers or domain jargon with no explanation of what they mean or where users can find them.
- Pointing 'Help' at a generic support homepage or FAQ that never mentions the task the user is actually stuck on.
- Hover-only tooltips as the sole help mechanism — invisible to keyboard and touch users, and non-conformant with 1.4.13 besides.
- Placeholder text as help: it vanishes on typing, exactly when the user needs to re-check the format.
- Help icons with no accessible name ('button, unlabeled') so screen reader users cannot even discover help exists.
- Help content written at a higher reading level than the form itself, defeating its own purpose (see 3.1.5).
- A chat assistant as the only help path, presented in a widget that is not keyboard-operable or screen reader compatible.
How to test for 3.3.5
- 1
List every input the page requires
Inventory the form fields and interactive inputs. For each, ask the honest question: could a first-time user, unfamiliar with your organization's vocabulary, answer this from the label alone?
- 2
For each hard field, locate the help
Find the hint text, example, help link, or assistant that addresses that specific field or task. It must be discoverable from the field — help that exists somewhere on the site but is not reachable in context does not count.
- 3
Check the help is genuinely context-sensitive
Follow each help link. Does it answer this task's questions (what the value is, where to find it, what format, what happens next), or does it dump the user on a generic portal to fend for themselves?
- 4
Operate every help mechanism by keyboard and screen reader
Tab to help buttons and links, open them with Enter/Space, and confirm hint text is announced with its field via aria-describedby. Hover-only tooltips and unlabeled icon buttons fail here.
- 5
Read the help itself for plainness
Help written in the same bureaucratic register as the form helps nobody. Check it against plain-language standards — short sentences, concrete instructions, an example.
This is a manual, judgment-based review — automated tools can verify an aria-describedby wiring but not whether the words help. Track it in your WCAG 2.2 checklist.
Relationship to the Input Assistance cluster
Guideline 3.3 forms a safety net around user input, and 3.3.5 is its proactive layer. 3.3.2 Labels or Instructions (A) guarantees the baseline label; 3.3.1 Error Identification (A) and 3.3.3 Error Suggestion (AA) handle the moment after a mistake — naming it and suggesting a fix. 3.3.5 works before the mistake: good context help prevents the error from ever being made, which is cheaper for everyone than the best error message.
At the far end of the pipeline, 3.3.4 Error Prevention (Legal, Financial, Data) (AA) and its AAA extension 3.3.6 Error Prevention (All) add review-and-confirm safety at submission. A form that provides help (3.3.5), labels well (3.3.2), explains errors (3.3.1, 3.3.3), and lets users confirm before committing (3.3.6) is the complete Input Assistance story.
Frequently asked questions
What does WCAG 3.3.5 Help require?
The normative text is three words: 'Context-sensitive help is available.' It means that when content requires user input — typically forms — help specific to the task and the field must be reachable at the point where the user needs it. That can be persistent field-level instructions, a help link next to the form or field, an example of the expected input, or an assistant. It is a Level AAA success criterion under Guideline 3.3 Input Assistance, applying at the page level: help for the function performed on that page.
What makes help 'context-sensitive' rather than just help?
Context-sensitive help answers the question the user has at the exact moment they have it: 'what goes in this field?', 'where do I find my policy number?', 'what format does this date want?'. A generic help center homepage, a site-wide FAQ, or a support email address is help, but not context-sensitive — the user must leave their task, search, and map generic answers back to their situation. The help must be tied to the specific input or task, and reachable from it.
How is 3.3.5 Help different from 3.3.2 Labels or Instructions?
3.3.2 (Level A) requires labels or instructions when content requires user input — the baseline 'tell people what to enter'. 3.3.5 (AAA) goes further: beyond the label, help must be available for users who need more than the label gives — clarification of purpose, format examples, where to find the requested information, or what happens with it. Think of 3.3.2 as the field's name tag and 3.3.5 as the knowledgeable colleague standing next to the form.
Does every form field need a help icon to pass 3.3.5?
No. The Understanding document is explicit that when a field's label is sufficient — 'First name', 'Email' — no additional help is required for it. The criterion targets input that people plausibly struggle with: unfamiliar identifiers (tax numbers, policy references), fields with strict formats, questions with legal or financial consequences, and multi-step tasks. Also, help can live at the form or page level (a 'Help with this form' link) rather than as per-field icons, as long as it actually covers the fields users get stuck on.
What forms of help satisfy 3.3.5?
The documented sufficient techniques include: instructions or hint text placed with the field, a help link on every page or beside the form that leads to task-specific help, examples of expected input ('e.g. AB-123456'), spell checking and suggestions for text input, and live assistants (human chat or a well-built automated assistant). Whatever the form, the help mechanism must itself be accessible — keyboard reachable, announced to screen readers, and dismissible per 1.4.13 if it appears on hover or focus.
Why is context-sensitive help an accessibility issue and not just good UX?
Because the cost of missing help is not evenly distributed. People with cognitive and learning disabilities may be unable to infer what an ambiguous field wants; people with memory impairments may not recall where to find an account number they've used before; people with anxiety may abandon a form rather than risk an error with legal consequences; screen reader users cannot skim the page for incidental clues sighted users pick up. Help available in context turns each of these hard stops into a recoverable moment — which is why it sits in the Input Assistance guideline alongside error prevention.
Related Success Criteria
Input errors are automatically detected and described to the user.
Labels or instructions are provided when content requires user input.
Input error suggestions are provided when errors are detected.
Important transactions can be reversed, checked, or confirmed.
All user input can be checked and confirmed before submission.