E-mail List Archives
Number of posts in this thread: 3 (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 | 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
>
From: Laurence Lewis
Date: Aug 2, 2025 4:04PM
Subject: Re: WCAG 2.2 SC 4.1.3 Status Message – Error Handling Across Multi-Part Date Input
← Previous message | No next message
Hi Dean
Thank you for taking the time to write such a comprehensive and thoughtful
response. I hadn’t expected such a detailed breakdown, and I really
appreciate the clarity you brought to the issue.
Your insights on how SC 4.1.3 applies in this context were incredibly
helpful.
Thanks,
Laurence Lewis
Accessibility Senior Specialist | Telstra
On Sun, 3 Aug 2025 at 4:00 am, < = EMAIL ADDRESS REMOVED = > wrote:
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: Weird bug in both JAWS and NVDA (maybe) (Léonie Watson)
> 2. Re: Weird bug in both JAWS and NVDA (maybe) (Patrick H. Lauke)
> 3. Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
> (Christine Hogenkamp)
> 4. scrollable content accessibility (David Farough)
> 5. Re: Weird bug in both JAWS and NVDA (maybe) (Sailesh Panchang)
> 6. Re: scrollable content accessibility (Sailesh Panchang)
> 7. WCAG 2.2 SC 4.1.3 Status Message – Error Handling Across
> Multi-Part Date Input (Laurence Lewis)
> 8. Re: WCAG 2.2 SC 4.1.3 Status Message – Error Handling
> Across Multi-Part Date Input ( = EMAIL ADDRESS REMOVED = )
> 9. Preferred order of items in a file? (Paul Rittman)
>
>
>
> ---------- Forwarded message ----------
> From: "Léonie Watson" < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Fri, 1 Aug 2025 19:06:13 +0100
> Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> This isn't a bug. It's the way the Accessible Name and Description
> Computation algorithm works [1].
>
> The short version is that ARIA takes precedence over all other sources
> for the accessible name, so in this case the content of the anchor is
> overridden by the value of the aria-label attribute.
>
> Léonie
> [1] https://www.w3.org/TR/accname-1.1/
>
>
>
>
> On 01/08/2025 18:49, Steve Green via WebAIM-Forum wrote:
> > I have been testing a website that contains some code that is nasty, but
> not strictly wrong as far as I can tell. Both JAWS and NVDA handle it in a
> way the developer would not have intended, and not only do they behave the
> same, but they do so with both Chrome and Firefox. I am told that Voiceover
> on macOS handles it differently, but I have not verified it and it's not
> particularly relevant. The code is very simple:
> >
> > <a href="#" aria-label="foo">
> > <h3>bar</h3>
> > </a>
> >
> > It's not obvious how you would expect a screen reader to announce this,
> but you would probably expect its announcements to include a link called
> "foo" and a heading called "bar". Or maybe a heading/link called "foo".
> Neither of these happen. JAWS and NVDA just announce a link called "foo"
> and nothing else. If the "aria-label" attribute is removed, they announce a
> heading/link called "bar", as you would expect.
> >
> > The accessibility tree shows that the <a> element has an accessible name
> of "foo" and that the heading contents are "bar". This looks correct to me
> and suggests that JAWS and NVDA are interpreting it incorrectly. But before
> I report the issue to both vendors I would be interested in the thoughts
> from this forum. Are the browsers doing something wrong? Is the correct
> behaviour ambiguous? Is the code invalid in a way I've missed?
> >
> > Steve Green
> > Managing Director
> > Test Partners Ltd
> >
>
> --
>
> Léonie Watson (she/her)
> Director
> https://tetralogical.com
>
> Looking to kick start or refresh your accessibility knowledge? Then
> sign-up for our free six day newsletter Accessibility Unlocked!
> <https://tetralogical.com/newsletters/accessibility-unlocked/>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Cc:
> Bcc:
> Date: Fri, 1 Aug 2025 19:11:49 +0100
> Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> The aria-label completely overrides whatever's inside that link, so this
> is as expected.
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Christine Hogenkamp < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Cc:
> Bcc:
> Date: Fri, 1 Aug 2025 15:00:58 -0400
> Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe) (Steve Green)
> Hi Steve,
>
> In terms of proper HTML, the header tag should go on the outside and the
> link would go inside. A link tag is by default an "inline" element like a
> span tag compared to a header tag, which by default is a display:block
> element. My understanding is that HTML5 is a bit more flexible about this
> and most modern browsers are more forgiving of incorrect HTML, but there
> may be assistive devices/tech that follows the rules of older HTML and
> operate in a more strict fashion.
>
> This may explain why you are experiencing some announcement issues.
>
> *x*
> *Christine Hogenkamp (She, Her)*
> Front-end Developer & Accessibility Lead
> Context Creative – a Mod Op company
> 416.972.1439 | contextcreative.com
>
>
> On Fri, Aug 1, 2025 at 2:00 PM < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Send WebAIM-Forum mailing list submissions to
> > = EMAIL ADDRESS REMOVED =
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> > or, via email, send a message with subject or body 'help' to
> > = EMAIL ADDRESS REMOVED =
> >
> > You can reach the person managing the list at
> > = EMAIL ADDRESS REMOVED =
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of WebAIM-Forum digest..."
> > Today's Topics:
> >
> > 1. Weird bug in both JAWS and NVDA (maybe) (Steve Green)
> > 2. Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Steve Green < = EMAIL ADDRESS REMOVED = >
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> > Cc:
> > Bcc:
> > Date: Fri, 1 Aug 2025 17:49:15 +0000
> > Subject: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> > I have been testing a website that contains some code that is nasty, but
> > not strictly wrong as far as I can tell. Both JAWS and NVDA handle it in
> a
> > way the developer would not have intended, and not only do they behave
> the
> > same, but they do so with both Chrome and Firefox. I am told that
> Voiceover
> > on macOS handles it differently, but I have not verified it and it's not
> > particularly relevant. The code is very simple:
> >
> > <a href="#" aria-label="foo">
> > <h3>bar</h3>
> > </a>
> >
> > It's not obvious how you would expect a screen reader to announce this,
> > but you would probably expect its announcements to include a link called
> > "foo" and a heading called "bar". Or maybe a heading/link called "foo".
> > Neither of these happen. JAWS and NVDA just announce a link called "foo"
> > and nothing else. If the "aria-label" attribute is removed, they
> announce a
> > heading/link called "bar", as you would expect.
> >
> > The accessibility tree shows that the <a> element has an accessible name
> > of "foo" and that the heading contents are "bar". This looks correct to
> me
> > and suggests that JAWS and NVDA are interpreting it incorrectly. But
> before
> > I report the issue to both vendors I would be interested in the thoughts
> > from this forum. Are the browsers doing something wrong? Is the correct
> > behaviour ambiguous? Is the code invalid in a way I've missed?
> >
> > Steve Green
> > Managing Director
> > Test Partners Ltd
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Steve Green < = EMAIL ADDRESS REMOVED = >
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> > Cc:
> > Bcc:
> > Date: Fri, 1 Aug 2025 17:55:56 +0000
> > Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> > It's worth mentioning that the heading also does not appear in JAWS'
> > Headings List and cannot be found using the screen reader's H or 3
> > shortcuts.
> >
> > Steve
> >