The 2025 TestParty Guide to WCAG 3.3.5 – Help (Level AAA)

Why did the form field go to therapy? Because it had too many issues and no one was there to help!

WCAG 3.3.5 Help ensures that users have access to context-sensitive assistance when filling out forms or providing input. While it's a Level AAA criterion—the highest conformance level—implementing help features improves usability for everyone, especially users with cognitive disabilities, learning differences, or those unfamiliar with your domain.

Table of Contents

• What WCAG 3.3.5 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 3.3.5
• How TestParty Helps
• FAQs

What WCAG 3.3.5 Requires

WCAG 3.3.5 requires that context-sensitive help is available to users when they interact with forms, inputs, or other interactive elements that require user input.

Key requirements:

• Help must be context-sensitive—relevant to the specific field, task, or section the user is working on
• Help can take multiple forms: instructions, examples, tooltips, help links, assistive tools, or live assistance
• The help doesn't need to be visible by default, but it must be easily discoverable and accessible
• Help should be available before errors occur, not just in error messages

What qualifies as help:

• Text instructions explaining what input is expected
• Data format examples (e.g., "MM/DD/YYYY" for dates)
• Tooltips or info icons that reveal guidance
• Help links that open relevant documentation
• Spell-checking or autocomplete suggestions
• Chatbots or virtual assistants embedded in the page

Important note: This is a Level AAA criterion, meaning it's not required for most legal compliance standards (which typically mandate Level AA). However, it represents best practice for inclusive design.

Why This Matters

Context-sensitive help reduces cognitive load and prevents errors before they happen. Users with cognitive disabilities, dyslexia, or attention disorders particularly benefit from clear, timely guidance.

From a legal perspective, WCAG 3.3.5 isn't typically required for ADA Title III, Section 508, or EN 301 549 compliance—those standards reference Level AA. However, government agencies, educational institutions, and organizations pursuing accessibility excellence often aim for AAA conformance on critical user journeys. The European Accessibility Act encourages going beyond minimum requirements where feasible.

The business case is compelling: forms with clear help have higher completion rates, fewer support tickets, and better user satisfaction. A 2023 Baymard Institute study found that 67% of cart abandonments involve form-related friction—much of which could be prevented with better contextual guidance.

Quick Implementation Guide

1. Add instructional text before complex form sections

Explain what information is needed and why before users encounter the fields:

<fieldset>
  <legend>Shipping Address</legend>
  <p class="form-help">
    Enter the physical address where you'd like your order delivered. 
    We cannot ship to P.O. boxes for this item.
  </p>
  <!-- form fields -->
</fieldset>

2. Provide format examples inline

Show users exactly what format you expect:

<label for="phone">
  Phone Number
  <span class="format-hint">(e.g., 555-123-4567)</span>
</label>
<input type="tel" id="phone" name="phone" 
       aria-describedby="phone-help">
<small id="phone-help">
  Include area code. We'll only call about order issues.
</small>

3. Use help links or tooltips for detailed guidance

Place help icons next to fields that need explanation:

<label for="tax-id">
  Tax ID Number
  <a href="/help/tax-id" target="_blank" 
     aria-label="Help with Tax ID Number">
    <svg aria-hidden="true"><!-- help icon --></svg>
  </a>
</label>

4. Implement spell-checking and suggestions

For text inputs, enable browser spell-checking or provide autocomplete:

<textarea id="comments" name="comments" 
          spellcheck="true"
          aria-describedby="comments-help">
</textarea>
<small id="comments-help">
  Describe any special delivery instructions.
</small>

5. Consider embedded assistance for complex forms

For multi-step processes (loan applications, medical forms), provide persistent access to help—whether through a chatbot, FAQ sidebar, or help panel.

Common Mistakes to Avoid

Hiding help behind unclear icons

Using a generic icon without a text label or tooltip makes help undiscoverable. Always provide clear labels like "Help" or "More information."

Only providing help in error messages

Waiting until users make mistakes defeats the purpose of context-sensitive help. Provide guidance proactively, before errors occur.

Making help available only on a separate help page

A generic help center doesn't meet this criterion. Help must be context-sensitive—tied to the specific field or task the user is working on.

Overloading forms with visible help text

While help should be available, you don't need to display everything at once. Use progressive disclosure (tooltips, expandable sections) to keep interfaces clean while making help accessible when needed.

How to Test for WCAG 3.3.5

Manual review checklist:

• Identify all forms and input fields on your site, especially those requiring specific formats or domain knowledge
• Check for help availability: Is context-sensitive help provided for each complex field or section?
• Verify help is discoverable: Can users easily find help without hunting? Are help icons clearly labeled?
• Test help quality: Does the help actually explain what's needed? Are examples provided for format-sensitive fields?
• Confirm accessibility: Is help text programmatically associated with fields (using aria-describedby)? Can keyboard users access help links and tooltips?

What automated tools can detect:

Automated scanners can identify:

• Missing aria-describedby associations between fields and help text
• Form fields without labels or instructions
• Help links that aren't keyboard-accessible

What requires human judgment:

• Whether help is truly context-sensitive and relevant
• Whether help is sufficient for the complexity of the input
• Whether help is discoverable in the user interface
• The overall quality and clarity of help content

WCAG 3.3.5 is heavily dependent on content quality and UX design, so manual review by accessibility specialists is essential.

How TestParty Helps

TestParty's AI-powered platform helps organizations identify gaps in context-sensitive help and implement solutions at scale, even though WCAG 3.3.5 requires significant human judgment.

What TestParty detects:

TestParty's automated scanning analyzes form structures and identifies:

• Input fields that lack associated help text or instructions
• Complex fields (dates, phone numbers, tax IDs, passwords) without format examples
• Forms missing introductory instructions or field grouping explanations
• Help links or info icons that aren't keyboard-accessible or properly labeled
• Missing aria-describedby associations between fields and help content
• Tooltips or help dialogs that don't meet ARIA authoring practices

TestParty flags these issues in its violation dashboard, prioritizing forms on high-traffic pages or critical user journeys (checkout, registration, account management).

How TestParty suggests fixes:

For many help-related issues, TestParty's AI generates code-level remediation:

• Auto-generated `aria-describedby` associations: TestParty suggests linking existing help text to form fields using proper ARIA attributes
• Format hint templates: For common field types (phone, date, SSN), TestParty recommends adding format examples based on detected input patterns
• Accessible help icon markup: TestParty provides code snippets for keyboard-accessible help buttons with proper ARIA labels
• Instructional text placement: TestParty identifies form sections that would benefit from introductory help and suggests where to insert guidance

Because help content quality requires human judgment, TestParty surfaces recommendations to content teams—flagging which fields need better explanations, examples, or links to documentation. These recommendations are reviewed by your team or TestParty accessibility specialists before implementation.

Developer workflow integration:

TestParty integrates into your development process to prevent help-related issues from reaching production:

• CI/CD gates: Block merges when new forms are introduced without help text or instructions
• Pull request annotations: Flag missing help associations or inaccessible help icons directly in code review
• Component library scanning: Ensure form components and design system elements include help patterns by default

For teams building forms in React, Vue, or other frameworks, TestParty validates that help props are used correctly and that help content is passed to components.

Ongoing monitoring:

TestParty continuously monitors your site for:

• New forms or fields added without help
• Changes to existing forms that remove or break help associations
• Help links that become broken or inaccessible
• Regression in help text quality after content updates

Dashboards track help coverage across your site, showing which forms meet WCAG 3.3.5 and which need attention. This is especially valuable for organizations with hundreds of forms across multiple properties or frequent form updates.

For organizations pursuing Level AAA conformance—government agencies, healthcare providers, educational institutions—TestParty provides audit-ready reports documenting help availability and quality across all user inputs.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 3.3.5

What is WCAG 3.3.5 in plain language?

WCAG 3.3.5 requires that users have access to context-sensitive help when filling out forms or providing input. This means providing instructions, examples, tooltips, or other guidance relevant to the specific field or task the user is working on. The help should be available before errors occur, not just in error messages.

Is WCAG 3.3.5 required for ADA compliance?

No, WCAG 3.3.5 is a Level AAA criterion, and ADA Title III compliance typically requires only Level AA conformance. However, providing context-sensitive help is a best practice that improves usability for all users and reduces legal risk by demonstrating a commitment to accessibility excellence.

What counts as "context-sensitive" help?

Context-sensitive help is guidance that's relevant to the specific field, section, or task the user is currently working on. Examples include format hints next to a phone number field, instructions explaining what a Tax ID is, or a tooltip describing password requirements. Generic help pages don't meet this criterion—the help must be tied to the user's current context.

Do I need to show all help text by default?

No, help doesn't need to be visible by default. You can use progressive disclosure techniques like tooltips, expandable sections, or help icons—as long as the help is easily discoverable and accessible to keyboard and screen reader users. The key is that users can find and access help when they need it.

Does spell-checking count as help for WCAG 3.3.5?

Yes, spell-checking and autocomplete suggestions are explicitly listed as sufficient techniques for WCAG 3.3.5. Enabling browser spell-checking on text inputs or providing intelligent suggestions helps users avoid errors and qualifies as context-sensitive assistance.