WCAG 3.3.1 Error Identification — Testing Guide for Mobile & Web Apps

WCAG 3.3.1, Error Identification, mandates that if an input error is automatically detected, the user must be informed of the error and provided a description of it in text. This applies to both web a

Ensuring WCAG 3.3.1 Compliance: Error Identification for All Users

WCAG 3.3.1, Error Identification, mandates that if an input error is automatically detected, the user must be informed of the error and provided a description of it in text. This applies to both web and mobile applications, ensuring users can understand and correct mistakes when interacting with your product.

What WCAG 3.3.1 Requires (In Plain English)

Essentially, if your application detects a user has made a mistake while filling out a form or interacting with an input field, you must clearly tell them *what* the mistake is and *where* it is. This feedback needs to be presented in a way that is easily understandable, typically through visible text. It’s not enough to just highlight an incorrect field; you need to explain the problem.

Why It Matters: Broadening User Access and Reducing Frustration

Adhering to WCAG 3.3.1 significantly broadens the accessibility of your application. Consider users with cognitive disabilities, learning disabilities, or those who are not fluent in the primary language of the application. Clear error identification prevents confusion and frustration, enabling them to complete tasks successfully.

For users with low vision or who rely on screen readers, clear, programmatically associated error messages are critical. Without them, they might not even realize an error has occurred, leading to repeated failed attempts and abandonment of the task. This is crucial for compliance with regulations like the EU's European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA), which mandate accessible digital experiences.

Common Violations and Real-World Examples

Violations of WCAG 3.3.1 often stem from a lack of clear, context-specific error messaging.

Mobile App Examples:

• Missing Required Field: A user attempts to submit a registration form without filling in their email address. The app might simply highlight the email field red, or worse, just show a generic "Please fill in all required fields" message *after* submission. Violation: The user isn't told *which* field is required.
• Invalid Phone Number Format: A user enters a phone number with an incorrect format (e.g., missing a digit, including letters). The app might display a cryptic error like "Invalid input" next to the phone number field. Violation: The user doesn't know the expected format.
• Password Strength Requirements Not Met: A user enters a password that doesn't meet complexity rules. The error message might be "Password too weak" without specifying *why* (e.g., needs a number, a special character, or minimum length). Violation: Lack of specific guidance on how to meet requirements.

Web App Examples:

• Date Format Mismatch: A user enters a date in "MM/DD/YYYY" format when the system expects "DD-MM-YYYY". The error message might be a generic "Invalid date." Violation: The user isn't told the correct format.
• Credit Card Number Length: A user enters a credit card number that is too short or too long. The system might just state "Invalid card number." Violation: No indication of the expected length or format.
• Search Query Too Short/Long: A search input field has length restrictions. If a user enters a query outside these bounds, a generic "Invalid search" message appears. Violation: The user doesn't know the acceptable character count.

How to Test for WCAG 3.3.1 Compliance

A multi-pronged approach combining manual checks and automated tools is most effective.

#### Manual Testing Steps:

1. Identify All Input Fields: Systematically go through every form and input element in your application.
2. Intentionally Trigger Errors: For each field, try to submit the form with invalid data. This includes:

• Leaving required fields blank.
• Entering data in incorrect formats (dates, numbers, emails, phone numbers).
• Exceeding character limits.
• Violating specific business rules (e.g., password complexity, age restrictions).

1. Observe Error Messages:

• Is an error message displayed?
• Is the message visible and easy to read?
• Does the message clearly state *what* the error is?
• Does the message clearly state *which* field has the error?
• Is the error message programmatically associated with the input field (e.g., using aria-describedby on the web)?
• Can users with screen readers easily access and understand the error message?

1. Test Error Recovery: After an error is displayed, can the user easily correct the input and resubmit without losing other entered data?

#### Automated Tools for WCAG 3.3.1 Checks:

• Browser Developer Tools (Web): Use accessibility audit tools built into Chrome, Firefox, Edge, etc. These can often identify missing aria attributes or basic form validation issues.
• Dedicated Accessibility Scanners (Web): Tools like Axe, Lighthouse, or WAVE can detect common programmatic errors related to form validation and ARIA usage.
• Mobile Accessibility Testers:
• Android Accessibility Scanner: This tool can identify issues like missing content descriptions, contrast problems, and some form field issues.
• Xcode Accessibility Inspector (iOS): Similar to the Android scanner, it helps identify accessibility issues in iOS apps.
• SUSA (SUSATest) Platform: As a comprehensive QA platform, SUSA includes specific checks for WCAG 3.3.1 during its autonomous exploration.

#### Mobile-Specific Considerations:

• Native Input Validation: Ensure native mobile input types (e.g., android:inputType="number", keyboardType="numeric" in iOS) are used appropriately. While not a direct WCAG check, they guide users and can prevent some invalid inputs.
• Screen Reader Behavior: Crucially, test how screen readers (TalkBack on Android, VoiceOver on iOS) announce errors. Errors should be announced immediately when they occur or upon form submission attempt, and clearly linked to the problematic field.
• On-Screen Keyboard Cues: For mobile, the on-screen keyboard often changes based on input type. Ensure this is correctly implemented to guide users.

How to Fix WCAG 3.3.1 Violations

Fixing these issues typically involves enhancing your form validation logic and presentation.

Web Application Code Example (HTML/JavaScript):

<div class="form-group">
  <label for="email">Email Address</label>
  <input type="email" id="email" name="email" aria-describedby="email-error" required>
  <p id="email-error" class="error-message" aria-live="polite"></p>
</div>

<script>
  const emailInput = document.getElementById('email');
  const emailError = document.getElementById('email-error');

  emailInput.addEventListener('blur', () => {
    if (!emailInput.value) {
      emailError.textContent = 'Email address is required.';
      emailInput.setAttribute('aria-invalid', 'true');
    } else if (!isValidEmail(emailInput.value)) {
      emailError.textContent = 'Please enter a valid email address (e.g., user@example.com).';
      emailInput.setAttribute('aria-invalid', 'true');
    } else {
      emailError.textContent = '';
      emailInput.removeAttribute('aria-invalid');
    }
  });

  function isValidEmail(email) {
    // Simple regex for demonstration; use a more robust one in production
    const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return re.test(String(email).toLowerCase());
  }
</script>

Key elements in the code:

• aria-describedby="email-error": Links the input field to the error message paragraph.
• id="email-error": Unique ID for the error message.
• class="error-message": For styling the error text (e.g., red color).
• aria-live="polite": Ensures screen readers announce the error message when it appears without interrupting the user.
• aria-invalid="true": Programmatically indicates the input field has an error.
• JavaScript Logic: Provides specific feedback based on whether the field is blank or the format is invalid.

Mobile Application Considerations:

• Android (Kotlin/Java): Use setError() on EditText views for simple text errors. For more complex scenarios or to ensure better screen reader integration, dynamically update a TextView associated with the input and ensure it's announced by the screen reader.
• iOS (Swift/Objective-C): Similar to Android, you can use label properties or dynamically update associated UILabel instances, ensuring they are accessible via UIAccessibility.

How SUSA Checks for WCAG 3.3.1 Compliance

SUSA's autonomous QA platform tackles WCAG 3.3.1 by integrating accessibility checks directly into its exploration engine.

• Autonomous Exploration: When you upload an APK or provide a web URL, SUSA explores your application's user flows, including forms and input fields.
• Persona-Based Testing: SUSA utilizes 10 distinct user personas, including novice, elderly, and accessibility, each designed to interact with the application in ways that expose potential usability and accessibility issues. These personas will intentionally attempt to submit forms with incorrect data.
• Error Detection and Identification: SUSA automatically detects if an input error occurs. It then analyzes the application's response to identify the error message.
• WCAG 2.1 AA Compliance: SUSA performs WCAG 2.1 AA accessibility testing, which includes specific checks for error identification. It verifies that:
• Errors are clearly identified in text.
• Error messages are programmatically associated with the relevant input fields.
• The error message provides a description of the error.
• Cross-Session Learning: With each run, SUSA learns more about your application, improving its ability to find and report errors, including those related to WCAG 3.3.1.
• Flow Tracking & Verdicts: For critical flows like registration or checkout, SUSA provides clear PASS/FAIL verdicts. If a user cannot complete a flow due to an unresolvable error or lack of clear error identification, the flow will fail.
• Reporting: SUSA generates detailed reports, including specific violations of WCAG 3.3.1, with screenshots and steps to reproduce, making it straightforward for developers to locate and fix issues. This ensures that your application remains accessible to a wider audience and compliant with accessibility standards.