WCAG 3.3.3: Error Suggestion

WCAG 2.x Success Criterion 3.3.3: Error Suggestion (Level AA)

This criterion ensures that when users make input errors that are automatically detected, and if a known correction can be suggested, that suggestion is provided to the user. This helps users recover from mistakes more easily and efficiently, reducing frustration and improving the overall user experience.

Why Error Suggestion Matters

Input errors are a common occurrence for all users, but they can pose significant barriers for individuals with certain disabilities:

• Users with cognitive disabilities: They may struggle to understand cryptic error messages or remember complex input formats. A clear suggestion can guide them directly to the correct input, reducing cognitive load and the likelihood of abandonment.
• Users with dyslexia or other learning disabilities: Typos are frequent. Providing a suggestion for a common misspelling (e.g., an email domain) can save them the effort of re-typing and re-checking.
• Users with mobility impairments: Re-typing lengthy or complex information due to an error can be physically demanding and time-consuming. An explicit suggestion, especially if clickable or autofillable, can significantly ease their interaction.
• Users with low vision: They may find it difficult to pinpoint the exact nature of an error or where to make a correction without explicit guidance.
• All users: Regardless of ability, clear and actionable error suggestions reduce frustration, save time, and make forms feel more forgiving and user-friendly. It leads to higher task completion rates and a more positive experience.

Success Criteria and Requirements

WCAG 2.0 and 2.1 Success Criterion 3.3.3 Error Suggestion (Level AA) states:

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Key aspects of this criterion include:

• Automatically detected: The system must identify that an error has occurred. This could be client-side (e.g., JavaScript validation) or server-side.
• Suggestions for correction are known: This implies that the system has enough information to offer a helpful, specific suggestion. For instance, if an email domain is misspelled (e.g., user@gmial.com), the system knows a likely correction (user@gmail.com). If an account number is simply ‘invalid’, and there’s no known common mistake, a suggestion might not be possible without jeopardizing security.
• Suggestions are provided: The suggestion must be presented to the user clearly and in an accessible manner. It should be associated with the error message and the input field.
• Unless it would jeopardize the security or purpose: This is a critical exception. For example, never suggest parts of a user’s password, security answers, or other sensitive information that could be used for malicious purposes. The purpose of the content might also be jeopardized if, for instance, a form is testing the user’s knowledge and providing a suggestion would defeat the test’s objective.

Practical Guidelines for Compliance

To meet SC 3.3.3, focus on making error messages informative, actionable, and accessible:

1. Identify common errors: Analyze user data or anticipate common mistakes (e.g., typos in email domains, incorrect date formats, transposed digits in IDs).
2. Provide clear and explicit suggestions: The suggestion should directly address the error and tell the user what to do. Avoid vague language.
3. Make suggestions easily actionable: Where possible, allow users to apply the suggestion with minimal effort (e.g., a clickable link that autofills the corrected value, or a clear example of the correct format).
4. Associate suggestions with error messages: Ensure the suggestion is presented alongside the error message and programmatically linked to the input field using ARIA attributes (e.g., aria-describedby).
5. Ensure accessibility for assistive technologies: Screen readers must be able to announce the error and its associated suggestion clearly.
6. Prioritize security and privacy: Absolutely avoid providing suggestions that could reveal sensitive user data or compromise account security.

Examples of Correct Implementations

Example 1: Email Address Typo Correction

When a user types a common misspelling of an email domain, the system suggests the correct domain.

<label for="email">Email address:</label>
<input type="email" id="email" name="email" aria-invalid="true" aria-describedby="email-error">
<div id="email-error" class="error-message" role="alert">
  <p>It looks like you entered <strong>@gamil.com</strong>. <br>Did you mean <a href="#" onclick="correctEmailDomain('gmail.com'); return false;">@gmail.com</a>?</p>
</div>

function validateEmail() {
  const emailInput = document.getElementById('email');
  const errorDiv = document.getElementById('email-error');
  const email = emailInput.value;
  const domain = email.split('@')[1];

  // Simple validation for demonstration
  if (email && domain && domain.includes('gamil.com')) {
    emailInput.setAttribute('aria-invalid', 'true');
    errorDiv.innerHTML = `<p>It looks like you entered <strong>@${domain}</strong>. <br>Did you mean <a href="#" onclick="correctEmailDomain('gmail.com'); return false;">@gmail.com</a>?</p>`;
    errorDiv.style.display = 'block';
  } else if (email && !email.includes('@')) {
    emailInput.setAttribute('aria-invalid', 'true');
    errorDiv.innerHTML = `<p>Please enter a valid email address. (e.g., user@example.com)</p>`;
    errorDiv.style.display = 'block';
  } else {
    emailInput.setAttribute('aria-invalid', 'false');
    errorDiv.style.display = 'none';
  }
}

function correctEmailDomain(newDomain) {
  const emailInput = document.getElementById('email');
  const currentEmail = emailInput.value;
  const username = currentEmail.split('@')[0];
  if (username) {
    emailInput.value = `${username}@${newDomain}`;
    validateEmail(); // Re-validate after correction
  }
}

document.getElementById('email').addEventListener('blur', validateEmail);

.error-message {
  color: #c00;
  font-size: 0.9em;
  margin-top: 5px;
  display: none; /* Hidden by default */
}

input[aria-invalid="true"] {
  border: 2px solid #c00;
}

.error-message a {
  font-weight: bold;
  text-decoration: underline;
  color: #007bff;
}

Example 2: Date Format Suggestion

When a user enters a date in an incorrect format, the system provides an example of the correct format.

<label for="dob">Date of Birth (DD-MM-YYYY):</label>
<input type="text" id="dob" name="dob" placeholder="DD-MM-YYYY" aria-invalid="false" aria-describedby="dob-error">
<div id="dob-error" class="error-message" role="alert"></div>

function validateDate() {
  const dobInput = document.getElementById('dob');
  const errorDiv = document.getElementById('dob-error');
  const dateValue = dobInput.value;
  const dateFormatRegex = /^d{2}-d{2}-d{4}$/;

  if (dateValue && !dateFormatRegex.test(dateValue)) {
    dobInput.setAttribute('aria-invalid', 'true');
    errorDiv.innerHTML = `<p>Incorrect date format. Please use DD-MM-YYYY (e.g., <strong>25-12-2023</strong>).</p>`;
    errorDiv.style.display = 'block';
  } else {
    dobInput.setAttribute('aria-invalid', 'false');
    errorDiv.style.display = 'none';
  }
}

document.getElementById('dob').addEventListener('blur', validateDate);

/* Same CSS as above for .error-message and input[aria-invalid="true"] */

Examples of Incorrect Implementations

Example 1: Generic Error Message Without Suggestion

The user is told there’s an error but receives no guidance on how to fix it.

<label for="username-incorrect">Username:</label>
<input type="text" id="username-incorrect" name="username" aria-invalid="true" aria-describedby="username-error-incorrect">
<div id="username-error-incorrect" class="error-message" role="alert">
  <p>Invalid Username.</p>
</div>

Example 2: Suggestion Jeopardizing Security

Attempting to suggest a correction for a password error could be a major security vulnerability.

<label for="password-incorrect">Password:</label>
<input type="password" id="password-incorrect" name="password" aria-invalid="true" aria-describedby="password-error-incorrect">
<div id="password-error-incorrect" class="error-message" role="alert">
  <p>Incorrect password. Did you mean <strong>P@ssw0rd123</strong>?</p>
</div>

Best Practices and Common Pitfalls

Best Practices:

• Be specific and actionable: Instead of "Invalid input," say "Please enter your 10-digit phone number, e.g., 555-123-4567."
• Use clear language: Avoid jargon or overly technical terms.
• Place suggestions logically: Position the suggestion immediately after the error message and near the input field it pertains to.
• Make suggestions easy to engage with: If a suggestion is a specific value (like a domain), make it clickable to auto-fill.
• Test with assistive technologies: Ensure screen readers announce both the error and the suggestion as a single, coherent message, thanks to proper ARIA linking (aria-invalid, aria-describedby).
• Provide alternatives for complex corrections: If a suggestion is difficult to formulate (e.g., "This account number does not exist"), consider offering a link to customer support or a knowledge base article.
• Client-side and Server-side Validation: Implement client-side validation for immediate feedback, but always re-validate server-side for security and robustness.

Common Pitfalls:

• Vague or generic error messages: Providing only "Error" or "Invalid entry" without any specific information or suggestion.
• Ignoring the security exception: Attempting to ‘help’ with sensitive fields like passwords, which directly violates the criterion and creates security vulnerabilities.
• Suggestions not being programmatically associated: A visual suggestion that isn’t conveyed to screen reader users via ARIA attributes.
• Suggestions that are not actionable: Telling a user they made a mistake but not giving them a clear path to correct it.
• Over-suggesting or being intrusive: While helpful, ensure suggestions don’t feel overwhelming or patronizing. Focus on high-impact, common errors.
• Inconsistent error handling: Different parts of a website handling errors in different, confusing ways.

By thoughtfully implementing WCAG 2.x SC 3.3.3 Error Suggestion, you significantly enhance the usability and accessibility of your forms, enabling more users to successfully complete their tasks.