Error Identification

In brief

A form that reloads with no sign of what went wrong leaves people guessing. People who cannot see a red border, who use a screen reader, or who have cognitive disabilities need to be told in words that there is an error and where it is.

This criterion requires that if an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

What does it cover?

• Input error: An input error is information provided by the user that is not accepted. It includes required information that was left out, and information outside the required format or values.
• Automatically detected: The criterion applies when the page detects the error itself, for example by validating a required field or a format.
• Identify the item: Say which field is in error, for example by naming it in the message or placing the message next to it.
• Describe in text: The error must be indicated in text. Colour, icons and other visual cues are allowed in addition, but not alone.
• Nature of the error: The description conveys what is wrong. Telling users how to fix it is 3.3.3.
• How it is shown: The criterion does not require a particular pattern. A summary, inline messages, an alert or a dialog can all work.
• Auto-corrected values: If the page silently changes an out-of-range value, the error must still be described.
• Native validation: Browser validation messages can meet the criterion, but they may not persist, may not scale with zoom, are often generic and show one error at a time.
• Out of scope: Programmatic error information is covered by 4.1.2, and status messages by 4.1.3.

Who does it affect?

People who are blind, who have low vision or colour vision deficiency, and cannot rely on a red outline. People with cognitive, language and learning disabilities who need to understand why a submission failed. Screen reader users who must be told that and where an error occurred. People who use magnification and see only part of the form.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Errors identified in text are part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.1 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.3.1 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. An error shown only by colour

A red border alone is not a text description.

<input id="email" style="border:2px solid red">

<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err" class="error">Enter an email address, for example [email protected].</p>

2. Mark the field and link the message (ARIA21)

aria-invalid flags the field and aria-describedby connects the message to it.

<input id="phone">
<span class="error">!</span>

<input id="phone" aria-invalid="true" aria-describedby="phone-err">
<span id="phone-err">The phone number must have 10 digits.</span>

3. Name the required field that was missed (G83)

Say which required field was left empty. Keep the other entries when the form is shown again.

<p class="error">Please correct the form.</p>

<p class="error">The "Last name" field is required.</p>

4. Announce the error

A live region or role="alert" makes screen readers read the message when it appears (ARIA19).

<div class="error" style="display:none">…</div> <!-- revealed silently -->

<div id="errors" role="alert"></div>
<script>
errors.textContent = "The \"Last name\" field is required.";
</script>

5. An error summary

List the errors at the top, each linked to its field, and move focus to the summary.

<!-- Form reloads with no summary and no messages -->

<div role="alert" tabindex="-1" id="summary">
  <h2>2 errors</h2>
  <ul>
    <li><a href="#email">Email: enter a valid address</a></li>
    <li><a href="#phone">Phone: 10 digits required</a></li>
  </ul>
</div>

6. A silently corrected value

If the page changes a value the user entered, say so.

qty.value = Math.min(qty.value, 10); // changed with no message

if (qty.value > 10) {
  qty.value = 10;
  msg.textContent = "The maximum is 10, so the quantity was set to 10.";
}

Code examples for mobile

Show the error in text next to the field, and make sure screen readers are told. Colour alone is not enough on a native screen either.

iOS (SwiftUI)

import SwiftUI

struct EmailField: View {
    @State private var email = ""
    @State private var error: String?

    var body: some View {
        VStack(alignment: .leading) {
            TextField("Email", text: $email)
                .onSubmit { validate() }
            if let error {
                // The error is text, not only a red border
                Text(error).foregroundStyle(.red)
            }
        }
    }

    private func validate() {
        if email.contains("@") { error = nil; return }
        error = "Enter an email address, for example [email protected]."
        // Tell VoiceOver users the error appeared
        AccessibilityNotification.Announcement(error ?? "").post()
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.error
import androidx.compose.ui.semantics.semantics

@Composable
fun EmailField() {
    var email by remember { mutableStateOf("") }
    val message = if (email.isNotEmpty() && !email.contains("@"))
        "Enter an email address, for example [email protected]." else null

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("Email") },
        isError = message != null,
        // The error is text, not only a red outline
        supportingText = { message?.let { Text(it) } },
        modifier = Modifier.semantics { message?.let { error(it) } }
    )
}

How to test

• Submit with errors: Leave required fields empty and enter invalid values. Does the page say in text that there is an error?
• Check the item: Is it clear which field is in error, from the message itself or its position?
• Remove the colour: View the page in greyscale or with colours off. Can you still tell where the errors are?
• Use a screen reader: Is the error announced when it appears, and is it connected to the field?
• Check native validation: If you rely on browser messages, test at 200% zoom and with several errors at once.
• Check auto-corrections: If the page changes a value, is the user told?
• Use a checker as a starting point: Automated tools can find missing aria-invalid and unlinked messages, but cannot judge whether the text describes the error. A person must read it.

Common mistakes

• Colour as the only cue: A red border or icon with no text.
• A generic message: "Please correct the errors" without saying which field.
• A message far from the field: With no link or reference to it.
• Errors that are not announced: Content inserted silently that screen readers never read.
• Clearing the form: Losing what the user entered when the error is shown.
• Placeholder text as the error: It disappears when the user types.
• Silent corrections: Changing a value with no explanation.
• Relying on alert() for everything: The message disappears when the dialog is closed and does not stay by the field.

Sources

• Understanding SC 3.3.1: Error Identification (W3C), opens in a new tab
• G83: Providing text descriptions to identify required fields that were not completed (W3C), opens in a new tab
• G85: Providing a text description when user input falls outside the required format or values (W3C), opens in a new tab
• ARIA21: Using aria-invalid to Indicate An Error Field (W3C), opens in a new tab
• ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.