Level AAA Understandable WCAG 3.3.5

What This Criterion Requires

WCAG 3.3.5 requires that context-sensitive help is available for form inputs and interactive elements when labels alone are not sufficient to describe the expected input. While WCAG 3.3.2 (Labels or Instructions) requires basic labels, this AAA criterion goes further by asking for detailed help that explains input formats, provides examples, and offers additional guidance when a task is complex. Context-sensitive help can take many forms: inline hint text below form fields, tooltips triggered by a help icon, expandable sections with detailed instructions, or links to comprehensive help documentation. The key requirement is that the help is available at the point where the user needs it, not buried in a separate FAQ page. This is particularly important for forms that require specific data formats, government or legal forms with specialized terminology, and multi-step processes where users need to make decisions. Providing contextual help reduces errors, decreases form abandonment, and makes interfaces usable by people with a wider range of cognitive abilities.

Why It Matters

Complex forms are one of the most significant barriers to digital inclusion. People with cognitive disabilities, learning disabilities, low literacy, or limited experience with digital interfaces struggle most when forms demand specific input formats without explanation. Consider a tax form that asks for a 'filing status' without explaining what each option means, or a registration form that requires a password meeting unlisted complexity rules. Without contextual help, users make errors, receive confusing error messages, and may abandon the process entirely. For government services, healthcare portals, and financial applications, this abandonment means people cannot access essential services. Even for commercial sites, poor form help directly increases support costs and reduces conversion rates. Research consistently shows that inline help text and examples reduce form completion time and error rates for all users, not just those with disabilities. Contextual help is one of the highest-ROI accessibility investments a team can make.

Common Failures and How to Fix Them

Password requirements not shown until error

A registration form requires passwords to meet specific complexity rules (minimum length, special characters, numbers) but does not display these requirements until the user submits and receives an error. Users must guess the rules through trial and error.

Inaccessible
<label for="password">Password</label>
<input type="password" id="password" name="password">
Accessible
<label for="password">Password</label>
<input type="password" id="password" name="password"
  aria-describedby="password-help">
<div id="password-help" class="help-text">
  Must be at least 8 characters and include a number, 
  an uppercase letter, and a special character (!@#$%^&*).
</div>

Form field expects specific format without example

A date field, phone number field, or reference number field requires input in a specific format but provides no example or hint about what format is expected. Users enter data in their preferred format and receive validation errors.

Inaccessible
<label for="phone">Phone number</label>
<input type="tel" id="phone" name="phone">
Accessible
<label for="phone">Phone number</label>
<input type="tel" id="phone" name="phone"
  aria-describedby="phone-help"
  placeholder="(555) 123-4567">
<div id="phone-help" class="help-text">
  Enter your 10-digit US phone number. Example: (555) 123-4567
</div>

Complex form with no inline guidance

A multi-step application form uses specialized terminology and asks users to make decisions (selecting a plan, choosing coverage options) without providing definitions, comparisons, or guidance at the point of decision.

Inaccessible
<fieldset>
  <legend>Select your coverage tier</legend>
  <label><input type="radio" name="tier" value="bronze"> Bronze</label>
  <label><input type="radio" name="tier" value="silver"> Silver</label>
  <label><input type="radio" name="tier" value="gold"> Gold</label>
</fieldset>
Accessible
<fieldset>
  <legend>Select your coverage tier</legend>
  <label><input type="radio" name="tier" value="bronze"
    aria-describedby="bronze-help"> Bronze</label>
  <div id="bronze-help" class="help-text">Lowest premium, highest deductible. 
    Best if you rarely visit the doctor.</div>
  <label><input type="radio" name="tier" value="silver"
    aria-describedby="silver-help"> Silver</label>
  <div id="silver-help" class="help-text">Moderate premium and deductible. 
    Good balance for regular checkups.</div>
  <label><input type="radio" name="tier" value="gold"
    aria-describedby="gold-help"> Gold</label>
  <div id="gold-help" class="help-text">Highest premium, lowest deductible. 
    Best if you have frequent medical needs.</div>
</fieldset>

How to Test

  1. Review all form fields and identify those that require specific formats, have complex rules, or use terminology that may not be universally understood.
  2. Verify that each complex field has associated help text, instructions, or examples that are visible without requiring the user to trigger an error first.
  3. Check that help text is programmatically associated with its field using aria-describedby so screen readers announce it when the field receives focus.
  4. Test with a screen reader to confirm that help text is announced in context when navigating to each form field.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria