Error Suggestion

In brief

Being told "invalid input" is not the same as knowing how to fix it. People with learning disabilities, low vision or motor impairments can lose a lot of time, or give up, when the form only says something is wrong.

This criterion requires that if an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user, unless it would jeopardise the security or purpose of the content.

What does it cover?

• Two conditions: The error is automatically detected, and the correction is known. If the page cannot know how to fix it, no suggestion is required.
• 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.
• Required format: When input does not match a required format, explain the format or show an example (G85, G177).
• Limited set of values: When the value must come from a list, say what the allowed values are (G84).
• Suggested correction text: If you can infer the intended value, offer it (G177), for example "Did you mean [email protected]?".
• The exception: A suggestion is not required if it would jeopardise the security or the purpose of the content. For example, a login page need not say which of the username and password was wrong.
• Who describes it: The author may describe the error, or the user agent may do so from programmatic information.
• Out of scope: Identifying the error is 3.3.1. Preventing mistakes in important transactions is 3.3.4.

Who does it affect?

People with learning and cognitive disabilities, who complete forms successfully when told how to fix them. People who are blind or have low vision, who better understand the error and the correction. People with motor impairments, who then re-enter values fewer times.

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. Help with correcting errors is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.3 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.3 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

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. Say how to fix it

The message should not only say the value is invalid.

<p class="error">Invalid date.</p>

<p class="error">The date must be in the format DD/MM/YYYY, for example 31/03/2026.</p>

2. Suggest the likely correction (G177)

If the intended value can be inferred, offer it.

<p class="error">Invalid email domain.</p>

<p class="error">Did you mean <button type="button">[email protected]</button>?</p>

3. List the allowed values (G84)

When the value must come from a set, name the set.

<p class="error">Value not allowed.</p>

<p class="error">Choose one of: small, medium, large.</p>

4. Explain a password rule

Say which rule failed and what is needed.

<p class="error">Weak password.</p>

<p class="error">Your password needs at least 12 characters and one number. It has 9 characters and no number.</p>

5. The security exception

A login need not reveal which part was wrong, because doing so could help an attacker.

<p class="error">No account exists for that email.</p> <!-- helps an attacker -->

<p class="error">The email or password is not correct. Try again or reset your password.</p>

6. Offer the correction without retyping

Where possible, let the user accept the suggestion with one action.

<p class="error">Postcode not found.</p>

<p class="error">We could not find postcode 3400 AB. Do you mean 3400 AB (Amsterdam)?
  <button type="button">Use this postcode</button></p>

Code examples for mobile

On mobile, typing is slower and corrections are costlier, so suggestions help even more. Offer a tap-to-accept suggestion and keep the message next to the field.

iOS (SwiftUI)

import SwiftUI

struct EmailEntry: View {
    @State private var email = "[email protected]"

    var body: some View {
        VStack(alignment: .leading) {
            TextField("Email", text: $email)
            if email.hasSuffix("@gmial.com") {
                // Tell the user what is wrong and offer the likely fix
                Text("Did you mean gmail.com?")
                Button("Use [email protected]") {
                    email = email.replacingOccurrences(of: "gmial.com", with: "gmail.com")
                }
            }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun EmailEntry() {
    var email by remember { mutableStateOf("[email protected]") }
    Column {
        OutlinedTextField(value = email, onValueChange = { email = it }, label = { Text("Email") })
        if (email.endsWith("@gmial.com")) {
            // Say what is wrong and offer the likely fix
            Text("Did you mean gmail.com?")
            TextButton(onClick = { email = email.replace("gmial.com", "gmail.com") }) {
                Text("Use [email protected]")
            }
        }
    }
}

How to test

• Trigger every error: Enter invalid, missing and out-of-range values. Does each message say how to correct it?
• Check the format: When a format is required, does the message state or illustrate it?
• Check the allowed values: When the value must come from a list, is the list given?
• Look for known corrections: Can the page infer the intended value, such as a mistyped domain, and suggest it?
• Apply the exception: Would a suggestion expose security information or defeat the purpose, for example on a login or a test?
• Read the message alone: Without seeing the form, could a person act on the message?
• Use a checker as a starting point: Automated tools cannot judge whether a suggestion helps. A person must read each message.

Common mistakes

• Only "invalid": The message says that something is wrong, not how to fix it.
• No example for a format: The date or phone format is never shown.
• Unnamed allowed values: The user must guess the options.
• Ignoring an obvious correction: A typo in a well-known domain is not suggested.
• Suggesting what the page cannot know: A wrong guess adds confusion.
• Revealing too much on login: Saying which of the username and password was wrong.
• Suggestions in a place users miss: A message at the top while the field is off-screen.
• Technical error codes: Messages the user cannot act on.

Sources

• Understanding SC 3.3.3: Error Suggestion (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
• G177: Providing suggested correction text (W3C), opens in a new tab
• ARIA18: Using aria-alertdialog 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.