WCAG 3.3.3: Error Suggestion

What This Rule Means

WCAG 3.3.3 Error Suggestion is a Level AA criterion under the Understandable principle. It builds directly on 3.3.1 (Error Identification), which requires that errors be identified in text. Error Suggestion goes further: when an input error is automatically detected, the interface must also suggest how the user can correct it, provided that suggestion does not compromise the security or purpose of the content.

The key distinction here is between error identification and error suggestion. Telling a user "Your date of birth is invalid" is identification. Telling a user "Your date of birth is invalid — please enter a date in DD/MM/YYYY format" is a suggestion. Both are required under their respective criteria, but Error Suggestion demands that actionable, corrective guidance accompany the error message wherever feasible.

The criterion applies whenever an input error is automatically detected — that is, when client-side or server-side validation logic determines that a submitted or entered value does not meet the expected criteria. It applies to all form controls: text inputs, selects, checkboxes, radio buttons, date pickers, file upload fields, and any interactive component that collects user data.

What counts as a pass: The error message is presented in text (not only through colour or icon), clearly identifies the field in error, and provides specific guidance on how to correct it. For example: "Password must be at least 8 characters and include one uppercase letter" rather than just "Invalid password." The suggestion must appear in proximity to the field, be programmatically associated with it (via aria-describedby or similar), and be perceivable by assistive technologies.

What counts as a fail: Any error message that merely states an error occurred without explaining what is wrong or how to fix it. Generic messages such as "Error," "Invalid input," or "Required field" without further context all fail this criterion. Errors communicated only through a red border or warning icon, with no descriptive text, also fail.

Defined exceptions: The criterion includes two explicit exceptions where a suggestion is not required. First, if providing the suggestion would jeopardize security — for instance, on a login form where explaining exactly why a password failed (wrong password vs. wrong username) could aid brute-force attacks. Second, if providing the suggestion would jeopardize the purpose of the content — for example, an educational quiz where revealing the correct answer defeats the assessment goal. These exceptions are narrow and should not be used to avoid the requirement in standard form contexts.

Why It Matters

Error Suggestion exists because completing forms is one of the most cognitively demanding activities users perform on the web, and it is also one of the most consequential — errors on checkout forms, government benefit applications, medical intake forms, or banking portals can have real-world consequences for users who cannot understand what went wrong or how to recover.

Cognitive disabilities: Users with dyslexia, ADHD, learning disabilities, or limited literacy may struggle to decode vague error messages and connect them to the specific field or required format. Without a clear corrective suggestion, they may abandon the form entirely or submit incorrect information. According to the World Health Organization, approximately 1 in 6 people globally — over 1.3 billion — live with some form of disability, and cognitive disabilities are among the most prevalent yet least accommodated categories.

Blind and low-vision users: Screen reader users rely entirely on text descriptions to understand validation errors. When an error message says only "Invalid" and provides no suggestion, the user has no mechanism to determine what "invalid" means for that field. They cannot glance at adjacent labels, placeholder text, or visual formatting cues to infer the expected format. A clear suggestion, programmatically associated with the input via aria-describedby, is the only reliable channel of information.

Motor-impaired users: Users relying on switch access, voice control, or alternative input devices experience significant physical effort when filling out forms. Having to re-navigate to a form after a failed submission — without understanding what needs to change — imposes a disproportionate cost. Clear suggestions reduce re-entry burden and the number of failed submission cycles.

Non-native language speakers and older users: Users who are not fluent in the form's language, or who have less experience with web conventions, also benefit substantially from explicit corrective suggestions. A message like "Enter your phone number without spaces or dashes, e.g. 05321234567" removes ambiguity for users who might otherwise never successfully complete the form.

Real-world scenario: Consider a Turkish citizen applying for a social assistance benefit through an e-government portal. The application requires a TR Identity Number (TC Kimlik Numarası), a specific 11-digit format. If the user enters 10 digits and receives only the message "TC Kimlik Numarası hatalı" (TC Identity Number is incorrect), a cognitively disabled user, elderly user, or screen reader user may not know whether the number is too short, contains an invalid character, or has a formatting issue. Adding "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (TC Identity Number must be 11 digits, e.g., 12345678901) immediately resolves the ambiguity and enables the user to self-correct.

Usability and conversion benefits: Beyond accessibility, form abandonment is a critical business metric. Research consistently shows that unclear error messages are among the top reasons users abandon e-commerce checkouts and registration flows. Specific, actionable error suggestions reduce form abandonment rates and improve completion rates for all users — making this criterion a strong business case as well as an accessibility requirement.

Related Axe-core Rules

WCAG 3.3.3 requires manual testing because automated tools cannot evaluate the quality or completeness of error message text. An automated scanner can detect that an error message exists and that it is programmatically associated with a form field, but it cannot determine whether the message actually provides a useful corrective suggestion. This requires human judgment to assess whether the text is specific, actionable, and sufficient to guide the user toward a valid entry.

• Manual review — error message content quality: Testers must manually trigger each validation condition (submit an empty required field, enter data in the wrong format, exceed character limits, etc.) and evaluate each resulting error message. The tester asks: does this message tell the user not only that an error occurred, but specifically what they should do to correct it? If the message is generic ("Invalid," "Error," "Please check this field"), it fails 3.3.3 regardless of whether it is programmatically exposed.
• Manual review — programmatic association: Testers must verify that the error suggestion text is programmatically linked to the relevant input field using aria-describedby, aria-live regions, or inline association, so that screen readers announce it without requiring additional navigation. This partially overlaps with axe rules such as label and aria-input-field-name, but the suggestion text itself is not checked by these rules.
• Manual review — security exception validity: Testers should verify that any form omitting corrective suggestions on security grounds (e.g., login forms) genuinely qualifies under the security exception, and that this exception is not being used to avoid the requirement on non-sensitive fields.
• Partially automated — label rule: While axe-core's label rule checks that form inputs have accessible names, it does not check whether error messages provide corrective suggestions. It can surface missing labels that would compound the error suggestion problem, and fixing label issues is a prerequisite for effective error suggestion implementation.

How to Test

1. Automated scan baseline: Run axe DevTools or Lighthouse against the page containing the form. Note any existing violations related to form labels, ARIA roles, or error identification (3.3.1). These must be resolved first, as they are prerequisites for effective error suggestion. Automated scans will not flag missing suggestions — they establish only the structural baseline.
2. Trigger every validation condition: For each form field, deliberately trigger every possible error state: submit an empty required field, enter data in an incorrect format (wrong date format, invalid email, too-short password, non-numeric value in a numeric field), and exceed any character limits. Document each error message that appears.
3. Evaluate suggestion quality: For each error message, ask: (a) Does it identify the specific field? (b) Does it explain what is wrong? (c) Does it provide actionable guidance on how to correct the entry? A message that answers all three passes 3.3.3. A message that answers only (a) passes 3.3.1 but fails 3.3.3.
4. Screen reader testing with NVDA + Firefox: Navigate to the form using Tab. Fill in an invalid value. Submit or move focus away. Listen to what NVDA announces. Verify that the error suggestion text is read aloud automatically (via an aria-live region or focus management to the error) without requiring the user to seek it out manually.
5. Screen reader testing with VoiceOver + Safari (macOS/iOS): Perform the same steps. Use VO+Right arrow to read the field and its associated description. Confirm that the suggestion text is announced as part of the field's accessible description, not just as nearby text that might be skipped.
6. Screen reader testing with JAWS + Chrome: After submitting a form with errors, confirm JAWS reads the error suggestion either through focus management (focus moved to the error summary) or through aria-live region updates. Use the JAWS virtual cursor to navigate to the field and confirm the suggestion is part of the field's description.
7. Keyboard-only navigation: Without a screen reader, navigate the form using only Tab, Shift+Tab, and Enter. Verify that error suggestions are visible in the viewport, not hidden off-screen or obscured by other elements, when the field receives focus after a failed submission.
8. Verify security exceptions: For login and authentication forms, confirm that the omission of specific suggestions is intentional and documented, and that the security exception is limited to the minimum necessary fields.

How to Fix

Generic error message — Incorrect

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Generic error message — Correct

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Password validation with no format guidance — Incorrect

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Password validation with no format guidance — Correct

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Date field with ambiguous format error — Incorrect

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Date field with ambiguous format error — Correct

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Multi-field form with server-side error summary — Incorrect

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Multi-field form with server-side error summary — Correct

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Common Mistakes

• Using placeholder as a substitute for error suggestions: Placeholder text disappears as soon as the user starts typing and is not reliably announced by screen readers as an error. Never rely on placeholder text alone to communicate what format is required after an error has occurred.
• Displaying error messages only in a toast notification that disappears after a few seconds: Transient notifications are not perceivable by all users — screen reader users may miss the announcement, and the message is gone before a slow reader can process it. Error suggestions must persist until the error is corrected.
• Using aria-invalid='true' without aria-describedby pointing to the suggestion text: Setting aria-invalid signals that a field has an error, but without aria-describedby linking to the suggestion element, screen readers will not read the suggestion text when the field is focused.
• Providing the suggestion only in the visual design (e.g., a tooltip on hover) and not in the DOM: Hover-only tooltips are inaccessible to keyboard users and screen reader users. The suggestion text must be present in the DOM and programmatically associated with the field.
• Using colour or iconography alone to indicate which field has an error: A red border or warning icon does not constitute an error suggestion. The suggestion must be a text description that explains the corrective action, not a visual indicator.
• Writing suggestions that identify the problem but not the solution: "Your password is too short" identifies the error but does not suggest a fix. "Your password must be at least 8 characters" provides the necessary corrective guidance. Both parts are required for 3.3.3 compliance.
• Applying the security exception too broadly: The security exception applies narrowly to situations where providing a suggestion would genuinely compromise security — typically limited to authentication fields. It does not apply to standard form fields like names, addresses, or phone numbers, where generic errors are unjustified.
• Placing the error suggestion after the submit button or far from the field: Error suggestions must be visually and programmatically proximate to the field they describe. Placing all errors at the bottom of a long form, without also including inline suggestions at each field, forces users to context-switch and remember which suggestion applies to which field.
• Failing to move focus to the error summary after a failed server-side submission: When a page reloads after a failed submission, focus typically returns to the top of the page. Without programmatic focus management to the error summary or the first field in error, screen reader users must navigate the entire page to discover what went wrong.
• Using vague language like "Please check your input" or "Something went wrong": These messages provide no information about what is wrong or how to fix it. Every error suggestion must be specific to the field and the specific validation rule that was violated.

Relation to Turkey's Accessibility Regulations

Turkey's accessibility landscape has advanced significantly with Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025. This circular establishes mandatory web and mobile accessibility requirements aligned with WCAG 2.2, with Level AA conformance required for entities seeking the Erişilebilirlik Logosu (Accessibility Logo) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Error Suggestion, as a Level AA criterion, falls within the scope of this mandatory requirement. Any covered entity that operates forms — for registration, payment, service applications, or account management — must ensure that their error messages do not merely identify errors but provide actionable corrective suggestions, as described in this criterion.

The entities covered by Presidential Circular 2025/10 span a wide range of sectors. Public institutions and government agencies are required to comply, meaning all e-government portals (e.g., e-Devlet services, municipal portals, benefit application systems) must provide compliant error suggestion implementations. Given that many government services require citizens to submit complex personal data — identity numbers, address codes, tax numbers — clear error suggestions are especially critical in this context.

Banks and financial institutions are covered, including online banking platforms, investment account registration forms, and loan application portals. These forms routinely collect sensitive and precisely formatted data, and the absence of corrective suggestions creates real barriers for disabled customers and potential legal exposure.

Hospitals and healthcare providers must also comply, covering patient registration systems, appointment booking forms, and insurance claim portals. Medical forms often involve complex field requirements (diagnosis codes, insurance policy numbers, precise date formats), making clear error suggestions especially important for elderly and cognitively disabled patients.

Telecommunications companies with 200,000 or more subscribers are covered, encompassing major operators' customer portals, SIM registration forms, and account management interfaces. E-commerce platforms — including checkout flows and account registration — must comply, making Error Suggestion directly relevant to product and cart management forms that are central to their business operations.

Travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE) are also within scope. Booking forms, enrollment applications, and payment interfaces operated by these entities must meet Level AA standards including 3.3.3.

From a practical compliance perspective, organizations pursuing the Erişilebilirlik Logosu should treat WCAG 3.3.3 as a key audit point during any accessibility assessment. Manual testing of all form validation flows — including both client-side and server-side error states — is required, and documentation of security exception rationale should be maintained for any fields where corrective suggestions are intentionally omitted. Failure to meet Level AA requirements, including Error Suggestion, will prevent award of the logo and may expose covered entities to administrative consequences under the circular.