WCAG 3.3.5: Help

What This Rule Means

\n

WCAG Success Criterion 3.3.5 Help (Level AAA) states: \"Context-sensitive help is available.\" This means that wherever a web page or application asks users to input information, appropriate help must be provided to clarify what is expected. The help must be contextual — that is, it must relate directly to the field, task, or process the user is currently engaged with, rather than being a generic help page buried somewhere in the navigation.

\n

The criterion applies to any user interface component that requires input: text fields, dropdown menus, date pickers, file upload controls, checkboxes, radio buttons, and multi-step forms. Context-sensitive help can take many forms, including inline instructions, descriptive labels, placeholder guidance, tooltips, help icons that expand explanations, links to relevant help articles, or even live chat support — as long as the help is available in proximity to the input that requires it.

\n

A pass is achieved when at least one of the following is present for each input that might cause user confusion: a clearly written label that fully explains the expected input; supplementary descriptive text adjacent to the field (not just a placeholder, which disappears on typing); a visible help link or expandable tooltip that provides further explanation; or an easily accessible help mechanism (such as a question-mark icon) that reveals guidance specific to the current context. The help does not need to be identical across all fields — the key requirement is that wherever a user might be uncertain about what to enter, help is genuinely available and accessible.

\n

A fail occurs when fields provide no explanation of what is expected, when help is only available after submission and an error occurs, when tooltips or help text are inaccessible to keyboard or screen reader users, or when help links lead to a general FAQ page rather than content relevant to the specific input. Critically, relying solely on error messages after the fact does not satisfy this criterion — help must be available before or during input, not only after a mistake has been made.

\n

WCAG 3.3.5 does not define a strict single implementation method. It acknowledges that context-sensitive help can be implemented in many valid ways, giving developers flexibility, but the intent is unambiguous: users should never be left guessing about what a form field expects. There are no official exceptions to this criterion — it applies universally wherever user input is requested.

\n\n

Why It Matters

\n

Forms are among the most challenging parts of any digital interface. For users with cognitive disabilities — including those with dyslexia, attention deficit disorders, intellectual disabilities, or memory impairments — ambiguous form fields can be an insurmountable barrier. Without clear, contextual help, these users may repeatedly fail to complete tasks, experience significant frustration, or abandon the process entirely. According to the World Health Organization, approximately 1 in 6 people worldwide live with some form of significant disability, and cognitive impairments represent a substantial portion of this population.

\n

Users with low digital literacy or limited experience with web interfaces also benefit enormously from context-sensitive help. A first-time user of a government e-services portal, an elderly person applying for a health benefit online, or a small business owner filling out a tax form may not know what format is expected for a tax identification number, what file types are accepted for document uploads, or what the difference between two similarly named fields represents. Without in-context guidance, these users are left vulnerable to errors and the anxiety of not knowing what they have done wrong.

\n

Consider a concrete scenario: a user with a cognitive disability is applying for a subsidized travel pass through a municipal transport authority's web portal. The form asks for a "Reference Number" with no explanation. The user has multiple documents — their national ID, their transit card, and a previous application confirmation — each with different numeric identifiers. Without context-sensitive help indicating which specific document or format is expected, the user is likely to enter the wrong number, trigger a validation error, and potentially give up. Had a simple help icon or inline description been present — "Enter the 10-digit number from the top-right corner of your transit card" — the entire interaction would have succeeded on the first attempt.

\n

For users who are blind or have low vision, context-sensitive help matters too. Screen readers can announce associated help text, aria-describedby descriptions, or linked help content, but only if these are properly implemented. When help is conveyed purely visually (as a color indicator or an icon without accessible text), screen reader users are excluded. Ensuring help is both present and accessible reinforces inclusivity across disability groups.

\n

Beyond accessibility, context-sensitive help improves overall usability and conversion rates. Websites with clear form guidance experience lower abandonment rates, fewer support requests, and higher form completion rates. For e-commerce sites in particular, every percentage point of improvement in checkout completion has direct revenue impact. Search engines also reward pages with clear, structured content, and well-labeled, well-described forms contribute positively to page quality signals.

\n\n

Related Axe-core Rules

\n

WCAG 3.3.5 requires manual testing because its compliance depends on the quality, relevance, and contextual appropriateness of help content — factors that automated tools cannot evaluate. An automated scanner can confirm that a label exists or that an aria-describedby attribute points to a real element, but it cannot determine whether the content of that label or description is actually helpful, accurate, or sufficient for a given input.

\n

\n
• Manual Review — Context-Sensitive Help Presence: Automated tools cannot assess whether help text genuinely addresses the user's likely questions about a specific field. A tool can detect that a <label> element exists, but cannot judge whether \"Enter your number\" is sufficiently descriptive for a field expecting a formatted VAT registration number. Manual testers must evaluate whether each input that could cause confusion is accompanied by guidance that meaningfully reduces that confusion.
\n
• Manual Review — Help Accessibility: Even if help is visually present, automated tools may not flag cases where that help is inaccessible to assistive technology. For example, a tooltip triggered only on mouse hover, without a keyboard-accessible equivalent, passes many automated checks but fails actual users. Testers must verify that all help mechanisms — tooltips, expandable sections, help links — are reachable and operable via keyboard and are announced correctly by screen readers.
\n
• Manual Review — Help Placement and Proximity: Automated scans cannot evaluate whether help text is placed close enough to the relevant field to be meaningfully associated with it. A help paragraph at the bottom of the page, or in a modal that requires multiple interactions to reach, may technically exist but fails the spirit of context-sensitive help. Manual review must confirm that help is available at the point of need.
\n
• Manual Review — Completeness Across Form Complexity: Complex, multi-step forms introduce additional challenges. Automated tools check individual fields in isolation but cannot assess whether the cumulative help provided across a multi-step wizard is sufficient to guide a user through a complex process. Manual walkthroughs are necessary to identify gaps in guidance that only become apparent when experiencing the form as a whole.
\n

\n\n

How to Test

\n

\n
1. Run an automated accessibility scan as a baseline. Use axe DevTools (browser extension or CLI), Lighthouse in Chrome DevTools, or IBM Equal Access Checker on the page containing the form. While these tools will not directly flag 3.3.5 violations, they will surface related issues such as missing labels (label element not associated with an input), missing aria-describedby targets, or inaccessible tooltip implementations. Resolving these foundational issues first ensures that when context-sensitive help is added, it is also technically accessible.
\n
2. Audit every form field manually for help availability. For each input field, ask: (a) Does the label alone fully explain what input is required, including any format requirements? (b) Is there supplementary help text visible adjacent to the field? (c) Is there a help icon, tooltip, or expandable section that provides further guidance? (d) Is there a link to relevant help content? If the answer to all of these is no, and the field has any ambiguity, this is a failure of 3.3.5.
\n
3. Test keyboard accessibility of all help mechanisms. Tab through the form using only a keyboard (no mouse). Verify that every tooltip, help icon, expandable description, or help link is reachable and activatable via keyboard. Tooltips should appear on focus as well as hover. Help buttons should be triggered with Enter or Space. Any help mechanism that is only reachable with a mouse fails this test.
\n
4. Test with NVDA + Firefox. Navigate to each form field using Tab. Listen to what NVDA announces for each field — does it announce the label? Does it announce any associated description (via aria-describedby)? Activate any help icons or tooltips and confirm their content is announced. Attempt to reach linked help content and verify it relates to the current field.
\n
5. Test with VoiceOver + Safari (macOS or iOS). Use VoiceOver to navigate the form. On macOS, use Tab to move between fields and listen to the full announcement for each. On iOS, use swipe navigation. Verify that all help content associated with inputs is read aloud, and that help triggers (buttons, links) are accessible and correctly labeled by VoiceOver.
\n
6. Test with JAWS + Chrome. Use JAWS forms mode (activate with Enter when on a form element). Navigate between fields with Tab and verify JAWS reads associated instructions and descriptions. Use the JAWS virtual cursor to check that help content placed outside standard label associations is also reachable.
\n
7. Conduct a cognitive walkthrough. Ask a person unfamiliar with the form (or simulate this by reviewing the form after a break) to attempt to complete it without any external guidance. Note every point where they hesitate, ask a question, or make an error due to unclear expectations. Each such point is a candidate for improved context-sensitive help under 3.3.5.
\n

\n\n

How to Fix

\n

Ambiguous Text Field with No Explanation — Incorrect

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Ambiguous Text Field with Inline Help — Correct

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Help Icon Tooltip Inaccessible to Keyboard Users — Incorrect

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Help Icon Tooltip Accessible to All Users — Correct

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Complex Multi-Step Form with No Step-Level Guidance — Incorrect

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Complex Multi-Step Form with Contextual Step Help — Correct

(Content truncated due to token limit — please retry this article.)