WCAG 3.3.1: Error Identification

What This Rule Means

WCAG 3.3.1 Error Identification is a Level A success criterion under the Understandable principle. It states: "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." In practical terms, whenever your website or application automatically validates user input — whether on form submission, on field blur, or in real time — two things must happen if an error is detected: the specific field or control that contains the error must be clearly identified, and the nature of the error must be communicated using actual text content (not solely color, icon, or sound).

The criterion applies to any situation where input is collected from users and validation occurs automatically. This includes HTML form elements such as <input>, <select>, <textarea>, as well as custom interactive widgets built with ARIA. It covers client-side validation triggered by JavaScript, native browser constraint validation using attributes like required, pattern, minlength, and type, as well as server-side validation results rendered after a page reload or injected dynamically into the DOM.

A pass requires that: (1) each field in error is programmatically associated with an error message — typically via aria-describedby or aria-errormessage — so assistive technologies can announce it; (2) the error message is in plain text visible in the UI (not hidden from sighted users); and (3) the text clearly describes what went wrong, not merely that something went wrong. For example, "Email address is required" is a valid error description, while displaying only a red border or an exclamation icon with no text alternative is a fail.

A fail occurs when: errors are indicated only through color changes (red border without text), errors are announced only via role="alert" without identifying which field is affected, the error message text is empty or generic (e.g., "Invalid input"), or error messages exist in the DOM but are not programmatically linked to the corresponding field so screen readers cannot associate them.

WCAG 3.3.1 does not apply when no automatic detection occurs — for instance, if a form is submitted and the server simply reloads the page without any indication of what went wrong, that is a separate usability failure but falls outside the strict scope of this criterion. However, if your system does perform automatic detection (which virtually all modern forms do), the criterion is fully in scope. There are no exceptions defined within the criterion itself for specific input types or use cases.

Why It Matters

Error identification directly affects multiple disability groups in significant ways. For blind and low-vision users who rely on screen readers such as NVDA, JAWS, or VoiceOver, a red border or a warning icon communicates nothing. If an error message is not present as actual text and is not programmatically associated with the field in error, the screen reader will not announce it, and the user may submit a form repeatedly without understanding why it is failing. According to the World Health Organization, approximately 2.2 billion people globally have some form of vision impairment, and millions rely on assistive technology daily to interact with web content.

For users with cognitive disabilities — including dyslexia, attention deficit disorder, and memory impairments — vague error messages like "Something went wrong" create significant barriers. These users benefit enormously from precise, descriptive error text that tells them exactly which field needs correction and what the correct format or value should be. For example, instead of "Invalid date," a message such as "Date of birth must be in DD/MM/YYYY format" is far more actionable.

Users with motor impairments who navigate by keyboard or switch devices expend significant effort moving through a form. When an error is unclear or unidentified, they must re-traverse the entire form to find the problem, greatly increasing the cognitive and physical cost of form completion. Clear error identification allows these users to jump directly to the problematic field.

Consider this real-world scenario: a Turkish citizen attempting to register on a government e-service portal to apply for a disability benefit. The form requires a national ID number in a specific format. The user, who is blind, enters their ID number. Upon submission, the form reloads with red-highlighted fields but no associated text error. The screen reader announces only the field labels again — the user has no idea what went wrong or which field is the problem. They abandon the process entirely, losing access to a critical public service. This is precisely the situation WCAG 3.3.1 is designed to prevent.

Beyond accessibility, clear error identification improves conversion rates and usability for all users. Studies in UX research consistently show that descriptive inline error messages reduce form abandonment. From an SEO perspective, improved user engagement signals — including longer time on site and successful form completions — positively influence search ranking over time.

Related Axe-core Rules

WCAG 3.3.1 requires manual testing for full verification. This is because automated tools can detect the presence or absence of structural patterns (such as aria-describedby or aria-errormessage), but they cannot evaluate whether the text content of an error message is meaningful, accurate, or sufficient to help the user understand and correct the error. An automated tool sees that a role="alert" element exists; it cannot judge whether the message "Error on line 4" adequately describes a validation failure to a screen reader user.

• aria-required-attr: This axe-core rule checks that elements with certain ARIA roles have all required ARIA attributes present. While not exclusively an error identification rule, it is relevant because a form field in an error state that uses role="textbox" or similar without the required attributes may fail to convey state information to assistive technologies, undermining error communication.
• aria-valid-attr-value: This rule flags cases where ARIA attributes reference IDs that do not exist in the DOM. For example, if a field uses aria-describedby="email-error" but no element with id="email-error" exists, the association is broken and the error message will not be read by screen readers. This is a common pattern failure for 3.3.1.
• Manual evaluation requirement: Testers must manually trigger validation errors and then use a screen reader to confirm that: the field in error is identified by name or label, the error description is announced, the message is meaningful and actionable, and the error is not communicated only through non-text means. Automated scans cannot simulate user interaction sequences or evaluate the semantic quality of message text, making human judgment indispensable for this criterion.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Run an axe DevTools scan on the page containing the form before and after triggering validation errors. Look specifically for violations related to broken aria-describedby or aria-errormessage references, missing role="alert" or aria-live regions used for dynamic error injection, and form fields missing labels (which also prevents proper error association). In Lighthouse, check the Accessibility audit for form-related violations. Note that a clean automated report does not confirm 3.3.1 compliance — it only rules out certain structural failures.
2. Manual keyboard navigation test: Using only a keyboard (Tab, Shift+Tab, Enter, Space), attempt to submit the form with intentionally incorrect or missing values. Verify that: focus moves to or near the first field in error, each error message is visible in the viewport, and the error messages identify the specific field by name and describe the problem in plain text.
3. Screen reader test with NVDA + Firefox: Open the form in Firefox with NVDA active. Submit the form with errors. Listen carefully: does NVDA announce which field has an error? Is the error description read aloud? Tab into the erroneous field — does NVDA read the associated error message as part of the field's accessible description? If using aria-live regions, verify the announcement is not delayed or suppressed.
4. Screen reader test with VoiceOver + Safari (macOS/iOS): Repeat the same process using VoiceOver on Safari. Use VO+Right Arrow to read through the form after submission. Confirm that each field in error includes the error text in its accessible name or description. On iOS, test using touch navigation and swipe gestures.
5. Screen reader test with JAWS + Chrome: With JAWS running in Chrome, submit the form with errors. Use the JAWS virtual cursor to navigate to each form field in error. Confirm that the error message text is included in JAWS' reading of the field. Check the JAWS forms mode behavior as well, since forms mode suppresses some live region announcements.
6. Color and non-text cue audit: Inspect each error state visually. Remove or disable CSS temporarily (using browser developer tools or a bookmarklet) and confirm that error identification is still present as text in the DOM. This verifies that error communication does not rely solely on color or iconography.
7. Dynamic injection check: For single-page applications or forms with real-time validation, use browser developer tools to inspect the DOM after an error is triggered. Confirm that the error message element exists in the DOM, contains non-empty text, and is referenced by the corresponding input via aria-describedby or aria-errormessage.

How to Fix

Scenario 1: Error indicated only by color — Incorrect

<!-- Fail: red border added via class, no error text associated -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS sets border: 2px solid red on .input-error -->
<!-- No error message text is rendered in the DOM -->

Scenario 1: Error indicated only by color — Correct

<!-- Pass: error text is present, visible, and linked to the input -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signals the error state to assistive technologies -->
<!-- aria-describedby links the input to its error message by ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Scenario 2: Generic error summary without field identification — Incorrect

<!-- Fail: a summary alert exists but does not identify which fields failed -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- No per-field error message; user cannot determine which field failed -->

Scenario 2: Generic error summary without field identification — Correct

<!-- Pass: summary lists specific fields in error, and each field has inline error text -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Inline error linked via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Scenario 3: Broken aria-describedby reference — Incorrect

<!-- Fail: aria-describedby references an ID that does not exist in the DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- The element with id='username-msg' was never rendered or was removed -->
<!-- Screen readers find no target and announce nothing for the description -->

Scenario 3: Broken aria-describedby reference — Correct

<!-- Pass: the referenced element exists in the DOM with matching ID -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Element with matching id is present and contains descriptive text -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Scenario 4: Real-time validation error injected dynamically — Incorrect

<!-- Fail: error injected into DOM but not associated with input; no live region -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- After blur, JavaScript appends this element, but no aria-describedby on input -->
<div class='error-text'>Password is too short.</div>

Scenario 4: Real-time validation error injected dynamically — Correct

<!-- Pass: error container pre-exists in DOM (empty), input references it; aria-live announces changes -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Empty span present at page load; JavaScript populates text and sets aria-invalid='true' on error -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript on blur: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Common Mistakes

• Using only CSS class changes (e.g., adding border-color: red) to indicate errors without any corresponding text in the DOM. Color alone is not perceivable by blind users or users with color blindness, and fails both 3.3.1 and 1.4.1.
• Writing aria-describedby on the input but pointing to an ID that is conditionally rendered or removed from the DOM on validation reset. The broken reference means the screen reader finds no associated content and the error is effectively invisible to assistive technology users.
• Using placeholder text as the sole error message. Placeholder text disappears when the user starts typing, is often low-contrast, and is not reliably announced by all screen readers as part of the field's description during error states.
• Injecting error messages dynamically into the DOM without ensuring they are associated with their parent field via aria-describedby. A visually adjacent error message is not automatically associated with an input — the programmatic link must be explicit.
• Displaying a page-level error summary without linking each summary item to the specific field in error. Users of screen readers or keyboard navigation need to be able to move directly from the error description to the field that requires correction.
• Setting aria-invalid='true' on a field but providing no error message text. The aria-invalid attribute signals that a field is in an error state but does not describe the error — it must be combined with a descriptive message.
• Providing error messages that are too generic, such as "Invalid input" or "Error in field." These descriptions do not explain what is wrong or how to fix it, failing the descriptive requirement of 3.3.1 and making error correction unnecessarily difficult for all users.
• Removing aria-live regions or role='alert' from error containers when resetting a form, causing the containers to vanish before screen readers have finished announcing their content. Error announcements can be cut off, leaving the user unaware of the validation result.
• Relying on native browser validation bubbles (the default browser tooltip popups) without customization. Native browser validation UIs are inconsistent across browsers and assistive technology combinations, and often do not meet WCAG requirements for identification and description in complex form scenarios.
• Placing error messages visually far from their associated fields — such as only in a header alert box — without also providing inline messages near each field. Users with low vision who magnify the screen may not see the header-level alert while focused on the input area, and keyboard users must travel significant distance to read the error.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements for a broad range of entities operating in Turkey. The circular adopts WCAG 2.2 as its technical standard, making all Level A success criteria — including WCAG 3.3.1 Error Identification — legally mandatory for covered organizations.

The compliance timeline set by the circular is one year for public institutions and two years for private sector entities from the date of publication. This means public institutions must achieve WCAG 2.2 Level A conformance by June 2026, and private sector covered entities by June 2027.

The entities covered by the circular include a wide cross-section of Turkish digital services. Public institutions — including all central government ministries, municipalities, state universities, and public agencies — are required to ensure their digital services are accessible. In the private sector, the circular covers e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

For all of these entities, WCAG 3.3.1 is directly relevant wherever online forms are used — which in practice means nearly every digital touchpoint. E-commerce checkout forms, bank account opening flows, hospital patient registration portals, government benefit application forms, airline and bus booking systems, and school enrollment pages all rely on form validation. If any of these systems automatically detect an input error and fail to identify the field or describe the error in text, they are in direct violation of the circular's requirements.

Non-compliance with the circular can expose covered entities to regulatory scrutiny, reputational risk, and potential penalties as Turkey's digital accessibility enforcement framework matures. Beyond legal compliance, adherence to 3.3.1 demonstrates a commitment to inclusive service delivery — ensuring that all citizens, including the approximately 8.5 million people with disabilities in Turkey (per TÜİK data), can access essential services online without barriers. Organizations operating under Accsible's SDK framework should prioritize both automated structural compliance and thorough manual testing to ensure their error handling fully satisfies this foundational criterion.