E-mail List Archives
Number of posts in this thread: 2 (In chronological order)
From: Laurence Lewis
Date: Aug 1, 2025 6:34PM
Subject: WCAG 2.2 SC 4.1.3 Status Message – Error Handling Across Multi-Part Date Input
No previous message | Next message →
Dear Accessibility Experts,
I'm seeking clarification on how WCAG 2.2 Success Criterion 4.1.3: Status
Messages (Level AA)
<https://www.w3.org/WAI/WCAG22/Understanding/status-messages> applies in
the following scenario:
A date range input is constructed using three separate form fields
displayed horizontally:
*Day* / *Month* / *Year* — e.g., DD/MM/YYYY.
If a user enters an invalid value in *any* of the three fields (e.g., "32"
in the Day input), an error message appears spanning underneath the group
of three inputs when the user leaves the field (onBlur). This error message
is *not* placed in a live region and therefore is not announced by a screen
reader at the time it appears.
My understanding has previously been that this may *not* strictly violate
SC 4.1.3 if the error is later programmatically exposed on form submission
(i.e., focus returns to the invalid field and the error is then announced).
However, on reviewing the Understanding document more closely —
particularly the *Success Techniques* section referencing *ARIA22* and
*G199* — it appears that *immediate* announcement is required when the
error message appears:
“After a user enters incorrect text in an input called Postal Code, a
message appears above the input reading 'Invalid entry'. The screen reader
announces, 'Invalid entry' or 'Postal code, invalid entry.'”
This would suggest that the failure to announce the error when it is
generated — even on blur — *is* a violation, given that screen reader users
are not informed of the error until the Submit button is clicked and
focus is sent to the first, if many, input in error. This is then announced
via aria-describedby on the input.
Given the structure of the date input (where the error spans multiple
related fields and input is sequential), announcing the error on blur could
be helpful, yet I’m also aware of potential confusion in a linear set of
controls, announcing onBlur would be confusing as the user has already left
the input in error and landed on the next focusable element or moved away
by virtual cursor. .
*My questions:*
- Is the absence of a live region announcement onBlur for an invalid
value in one of the date inputs a *strict violation* of 4.1.3? Or any
time this functionality occurs.
I welcome any thoughts or references to existing interpretations. I'm happy
to be corrected as part of continuous learning.
Thanks,
Laurence Lewis
Accessibility Senior Specialist | Telstra
From: Dean.Vasile---
Date: Aug 1, 2025 7:31PM
Subject: Re: WCAG 2.2 SC 4.1.3 Status Message – Error Handling Across Multi-Part Date Input
← Previous message | No next message
This is an excellent and nuanced question that gets to the heart of what SC 4.1.3 aims to achieve: providing timely and non-intrusive feedback to screen reader users about changes on the page that they might otherwise miss.
Based on the scenario you've described, the absence of a live region announcement on onBlur for the invalid date input is a strict violation of 4.1.3.
Here's a breakdown of the reasoning:
1. The Purpose of SC 4.1.3
The core of this criterion is to ensure that status messages, which convey information about a change in the state of the content, are programmatically determined to be a status message. This allows assistive technologies (like JAWS, NVDA, and VoiceOver) to announce them to the user without necessarily moving focus or interrupting the user's workflow. The key phrase here is "without receiving focus." A message that appears visually but is not announced until the user interacts with the submit button and focus is programmatically moved to the field is not a "status message" in the sense that the criterion intends.
2. The Definition of a Status Message
A status message is defined as "A change in content that is not a change of context, and provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors." In your scenario, the error message appearing underneath the date input is a clear example of a status message—it informs the user of an error.
3. The onBlur Event and User Awareness
You've astutely noted the potential for confusion with onBlur announcements. However, the intent of SC 4.1.3 is to prevent a gap in information. When a sighted user enters "32" in the day field and tabs away, they immediately see the error message appear. A blind user who tabs to the month field or moves their virtual cursor away will not receive this same information. They are unaware of the error until they attempt to submit the form, which could be much later. This creates a significant disparity in the user experience.
4. The Role of Live Regions
The recommended technique for implementing SC 4.1.3 is the use of an ARIA live region. When the error message is dynamically inserted into or updated within an aria-live region (e.g., aria-live="polite"), the screen reader will announce the change without focus needing to be moved. The polite setting is crucial here, as it waits for the user's current task to be completed (like tabbing to the next field) before announcing the message, thus avoiding interruption. This is precisely the solution for the potential confusion you mentioned regarding the onBlur event.
5. The "Form Submission" Argument
Your previous understanding that it might not be a violation if the error is announced on form submission is a common point of confusion. While providing error feedback on form submission is a crucial part of accessibility (covered by SC 3.3.1 Error Identification), it does not satisfy the requirements of 4.1.3. SC 4.1.3 addresses the specific case of dynamic status changes that are not a change of context. The error message that appears on onBlur is a dynamic status change that should be announced immediately to satisfy the criterion. Relying solely on form submission feedback creates a non-equivalent experience where a blind user must perform a separate action (submitting the form) to receive information that a sighted user receives automatically.
In summary:
The failure to announce the error message when it appears onBlur is a strict violation of 4.1.3 because it is a status message that is not programmatically announced to the user at the time of its appearance. To be compliant, the error message container should be a live region with a polite setting, ensuring that the error is announced in a timely manner without disrupting the user's flow.
Dean Vasile
IAAP, CPACC
= EMAIL ADDRESS REMOVED =
617-799-1162
> On Aug 1, 2025, at 8:35 PM, Laurence Lewis via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>
> Dear Accessibility Experts,
>
> I'm seeking clarification on how WCAG 2.2 Success Criterion 4.1.3: Status
> Messages (Level AA)
> <https://www.w3.org/WAI/WCAG22/Understanding/status-messages> applies in
> the following scenario:
>
> A date range input is constructed using three separate form fields
> displayed horizontally:
> *Day* / *Month* / *Year* — e.g., DD/MM/YYYY.
>
> If a user enters an invalid value in *any* of the three fields (e.g., "32"
> in the Day input), an error message appears spanning underneath the group
> of three inputs when the user leaves the field (onBlur). This error message
> is *not* placed in a live region and therefore is not announced by a screen
> reader at the time it appears.
>
> My understanding has previously been that this may *not* strictly violate
> SC 4.1.3 if the error is later programmatically exposed on form submission
> (i.e., focus returns to the invalid field and the error is then announced).
> However, on reviewing the Understanding document more closely —
> particularly the *Success Techniques* section referencing *ARIA22* and
> *G199* — it appears that *immediate* announcement is required when the
> error message appears:
>
> “After a user enters incorrect text in an input called Postal Code, a
> message appears above the input reading 'Invalid entry'. The screen reader
> announces, 'Invalid entry' or 'Postal code, invalid entry.'”
>
> This would suggest that the failure to announce the error when it is
> generated — even on blur — *is* a violation, given that screen reader users
> are not informed of the error until the Submit button is clicked and
> focus is sent to the first, if many, input in error. This is then announced
> via aria-describedby on the input.
>
> Given the structure of the date input (where the error spans multiple
> related fields and input is sequential), announcing the error on blur could
> be helpful, yet I’m also aware of potential confusion in a linear set of
> controls, announcing onBlur would be confusing as the user has already left
> the input in error and landed on the next focusable element or moved away
> by virtual cursor. .
>
> *My questions:*
>
> - Is the absence of a live region announcement onBlur for an invalid
> value in one of the date inputs a *strict violation* of 4.1.3? Or any
> time this functionality occurs.
>
>
>
> I welcome any thoughts or references to existing interpretations. I'm happy
> to be corrected as part of continuous learning.
>
> Thanks,
> Laurence Lewis
> Accessibility Senior Specialist | Telstra
>