Back to reviews and guides

WCAG 3.3.5 Help: Providing Accessible Help and Support

This guide explains how to meet the intent of WCAG 3.3.5 by making help and support accessible across channels. It gives practical steps, a checklist, common fixes and a retrofit plan.

What WCAG 3.3.5 means for help and support

WCAG 3.3.5 refers to the requirement many accessibility frameworks use to ensure help and support are accessible. The intent is simple: anyone who needs assistance using a site or service must be able to get that assistance without barriers. This page shows practical steps to design help content, channels and tools that work with assistive technology and plain language.

Why accessible help matters

  • People with cognitive, visual, hearing or motor impairments often need clearer instructions or an alternative contact channel.
  • Inaccessible help leads to abandoned tasks, failed transactions and frustration.
  • Accessible help reduces support calls by providing usable self-service resources.

Where you must provide accessible help

Provide help close to the task and through at least one direct contact option. Common places to add accessible help include:

  • Inline guidance near form fields and controls
  • Dedicated help pages or knowledge bases
  • Accessible contact forms and email addresses
  • Phone support with alternative text-based channels
  • Live chat and chatbot services with accessibility features
  • Video and audio help with captions and transcripts

How to make help pages and FAQs accessible

Use clear headings and structure

Use semantic headings (<h2> to <h3>) and short paragraphs. Headings must describe the content that follows so screen reader users can scan quickly.

Write in plain language

Keep sentences short. Use common words. Define any domain terms. Add examples and step-by-step instructions where a task is complex.

Provide multiple ways to find help

Include a visible search box, a clearly labelled table of contents and links to the most common tasks. Make sure the search results are accessible.

How to make contact channels accessible

Accessible contact forms

  • Use proper <label> elements and associate them with inputs via for or implicit wrapping.
  • Provide descriptive error messages and point to the field in error.
  • Avoid CAPTCHAs that block people who cannot use them. Offer an accessible alternative such as an email/phone route.
  • Allow attachments and provide clear file size and format instructions.

Phone and voice support

  • Publish a phone number and clear hours. Offer a text alternative such as SMS, WhatsApp or email.
  • Provide options for relay services and TTY where available.

Live chat and chatbots

  • Ensure keyboard focus moves into the chat widget and can return to the page.
  • Make transcripts available and provide a way to escalate to a human in plain language.
  • Label chat controls and status changes using ARIA live regions when needed.

Email and asynchronous support

  • Use plain subject lines that describe the issue type. Give expected response times.
  • Format replies so screen readers read them predictably. Avoid complex tables in emails.

Making multimedia help accessible

All video and audio help should include captions, synchronized text captions for speech, and a full transcript. For demonstrations, include descriptive audio or a written step-by-step alternative.

Technical accessibility details to implement

  • Use semantic HTML for all help content; avoid presenting content using images of text.
  • Ensure keyboard-only users can access every help control and focus order is logical.
  • Expose dynamic updates through WAI-ARIA roles and live regions when necessary, and test with screen readers.
  • Follow colour contrast rules for text and controls to maintain readability.

Practical checklist to meet WCAG 3.3.5 intent

  1. Provide inline help for every complex field or interaction.
  2. Publish at least two accessible contact channels, one text-based.
  3. Offer captions and transcripts for every help video and audio file.
  4. Make contact forms fully keyboard accessible with proper labels and error handling.
  5. Include escalation instructions so users can get human help when automated routes fail.
  6. Test help flows with people who use screen readers, magnifiers and keyboard only.

Common mistakes and how to fix them

  • Relying on CAPTCHA without alternatives. Fix: add an accessible alternate route such as email or phone.
  • Hiding help behind modal dialogs that trap keyboard focus. Fix: manage focus correctly and provide a clear close control.
  • Using video without captions or transcript. Fix: add captions and a time-stamped transcript.
  • Providing only a phone number. Fix: add a text-based option and clear response times.

Step-by-step retrofit plan for existing sites

  1. Inventory all help content and channels. Note format, location and media type.
  2. Prioritise high-impact pages: checkout, account settings and forms that collect data.
  3. Update one page at a time: add labels, inline help, captions, and an accessible contact link.
  4. Test each page with assistive tech and at least two real users with disabilities.
  5. Train support staff on accessible communication and escalation procedures.
  6. Monitor support metrics and feedback to catch recurring barriers.

Testing and validation

Automated checkers catch many issues but not everything. Combine automated tests with manual checks and user testing. Key manual checks:

  • Keyboard-only navigation through help pages and contact forms.
  • Screen reader walkthroughs of help content and live chat flows.
  • Play video with captions on and read the transcript for completeness.
  • Confirm dynamic updates announce to assistive tech when content changes.

Example accessible help text template

Use this short template for inline help near form fields:

  • Label: Clear field name
  • Short hint: One-line example of expected input
  • More info link: Link to a short help article or example
  • Error message: Describe the problem and how to fix it

Next steps for teams

Create a policy that defines accessible help channels, response times and training. Add help checks to your release checklist and include people with disabilities in testing. Accessibility is ongoing work. Start with the highest-value pages and expand from there.

Further reading

Refer to the Web Content Accessibility Guidelines and WAI-ARIA documentation for technical requirements and examples. Combine those resources with real-user testing to confirm your help is usable by everyone.