E-mail List Archives
Number of posts in this thread: 8 (In chronological order)
From: Steve Green
Date: Jun 13, 2025 3:28AM
Subject: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
No previous message | Next message →
I have always believed that SC 4.1.3 required the use of ARIA live regions, not least because none of the Sufficient Techniques use any other method.
However, it has been suggested that in the case of inline error messages next to form controls, an "aria-describedby" attribute can be used to meet the success criterion. I am sceptical and would like to get further opinions.
I have done some testing with NVDA, and it seems to work something like a live region on the website I'm testing, but I don't consider the undocumented behaviour of one assistive technology to be sufficient. It might just coincidentally work for this website with this NVDA version. What do you think?
Regards,
Steve Green
Managing Director
Test Partners Ltd
0800 612 2780 (switchboard)
07957 246 276 (mobile)
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: Steve Green
Date: Jun 13, 2025 3:43AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
A further thought. Does it make a difference if the focus is automatically moved to the field that is in error?
I don't like to rely on this technique, but I want to be sure it's not conformant before asking the client to change all their forms - there are a lot of them.
Steve
From: Patrick H. Lauke
Date: Jun 13, 2025 3:48AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
If it satisfies the non-tech-specific ask of the SC - that status
messages (like error messages for a form that are shown dynamically) are
conveyed explicitly to AT users - then it passes.
If you're concerned that a particular approach only works due to a quirk
of only one particular AT implementation, it's worth testing in others
to see if it's accessibility-supported enough.
FWIW I've been happy to pass things using aria-describedby when it was
consistently announced.
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Steve Green
Date: Jun 13, 2025 4:08AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
Thanks Patrick, that's really helpful. Do you think it's worth starting a discussion on the W3C WAI group to see if this should be added to the Sufficient Techniques? I feel a lot happier recommending techniques that are listed there.
FWIW, the website also has live regions, but they have been implemented so badly that they don't work at all. I would prefer to get the client to fix them, but I'm sure they won't if "aria-describedby" is sufficient.
Steve
From: Patrick H. Lauke
Date: Jun 13, 2025 4:35AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
On 13/06/2025 11:08, Steve Green wrote:
> Thanks Patrick, that's really helpful. Do you think it's worth starting a discussion on the W3C WAI group to see if this should be added to the Sufficient Techniques? I feel a lot happier recommending techniques that are listed there.
>
Suggest opening an issue or PR on the WCAG repo.
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Steve Green
Date: Jun 16, 2025 10:23AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
I have given this a great deal of thought, helped greatly by Adrian Roselli's article at https://adrianroselli.com/2023/04/exposing-field-errors.html. My conclusion is that the “aria-describedby” attribute is not suitable for use as a live region with respect to conformance with success criterion 4.1.3. I will therefore not open an issue on the WCAG repo at this stage.
For those who care about this arcane topic, the arguments for and against are:
For
* Section 4.8.1 of the W3C Core Accessibility API Mappings 1.2<https://www.w3.org/TR/core-aam-1.2/#mapping_events_state-change> specification states that changes in the value of the “aria-describedby” attribute must be exposed as an event via the accessibility API (which would trigger the live region). This is currently a draft specification.
* The technique works with NVDA screen reader and Chrome on Windows 11.
* The technique should work with other Chromium-based browsers such as Microsoft Edge, Opera and Samsung Internet.
Against
* This use of the “aria-describedby” attribute is not included in any of the Sufficient Techniques for success criterion 4.1.3.
* Section 5.8.1 of the W3C Core Accessibility API Mappings 1.1<https://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change> specification does not include the “aria-describedby” attribute. This is the current version of the specification. We do not know when v1.2 will be published or whether it will be modified before publication.
* The technique is unlikely to currently work with other browsers such as Firefox and Safari. We do not know if or when they will adopt the W3C Core AAM 1.2 specification.
* It is possible that the technique only works if the website automatically moves the focus to the form control that is in error.
* We have not tested the technique with any other Chromium-based browsers or any other assistive technologies. In 2023, Adrian Roselli tested this and some other techniques with a large number of browsers and assistive technologies. His results are in line with our expectations.
Steve
From: Sailesh Panchang
Date: Jun 16, 2025 6:52PM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | Next message →
The SC specifically states the status is exposed by change in role or in a
manner that does not require the status message to receive focus.
Aria-describedby, aria-labelledby, aria-label are designed to make
associated content programmatically determinable when the particular
element receives focus.
As such these cannot be used solely to satisfy SC 4.1.3 IMO.
Sailesh Panchang
Principal Accessibility Consultant
Email: = EMAIL ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Mon, Jun 16, 2025 at 12:23 PM Steve Green via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> I have given this a great deal of thought, helped greatly by Adrian
> Roselli's article at
> https://adrianroselli.com/2023/04/exposing-field-errors.html. My
> conclusion is that the “aria-describedby” attribute is not suitable for use
> as a live region with respect to conformance with success criterion 4.1.3.
> I will therefore not open an issue on the WCAG repo at this stage.
>
>
>
> For those who care about this arcane topic, the arguments for and against
> are:
>
>
>
> For
>
> * Section 4.8.1 of the W3C Core Accessibility API Mappings 1.2<
> https://www.w3.org/TR/core-aam-1.2/#mapping_events_state-change>
> specification states that changes in the value of the “aria-describedby”
> attribute must be exposed as an event via the accessibility API (which
> would trigger the live region). This is currently a draft specification.
> * The technique works with NVDA screen reader and Chrome on Windows 11.
> * The technique should work with other Chromium-based browsers such as
> Microsoft Edge, Opera and Samsung Internet.
>
>
>
> Against
>
> * This use of the “aria-describedby” attribute is not included in any
> of the Sufficient Techniques for success criterion 4.1.3.
> * Section 5.8.1 of the W3C Core Accessibility API Mappings 1.1<
> https://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change>
> specification does not include the “aria-describedby” attribute. This is
> the current version of the specification. We do not know when v1.2 will be
> published or whether it will be modified before publication.
> * The technique is unlikely to currently work with other browsers such
> as Firefox and Safari. We do not know if or when they will adopt the W3C
> Core AAM 1.2 specification.
> * It is possible that the technique only works if the website
> automatically moves the focus to the form control that is in error.
> * We have not tested the technique with any other Chromium-based
> browsers or any other assistive technologies. In 2023, Adrian Roselli
> tested this and some other techniques with a large number of browsers and
> assistive technologies. His results are in line with our expectations.
>
>
>
> Steve
>
>
>
From: Steve Green
Date: Jun 17, 2025 12:33AM
Subject: Re: Techniques for meeting WCAG SC 4.1.3 (Status Messages)
← Previous message | No next message
That is true at the moment, but it seems that it will change when W3C Core Accessibility API Mappings 1.2 becomes a recommendation because aria-describedby will be added to the list of properties that should trigger an event when they change. It therefore appears that, subject to there being sufficient accessibility support, aria-describedby will work as a live region.
Chromium-based browsers already support this, which is what started my investigation into the topic. I am testing a website where the live regions are implemented incorrectly and do not work, yet form controls that have aria-describedby attributes behave as if they do have live regions.
I have to say I don’t understand the API Mappings specification well, so I welcome input from anyone who does.
Steve
From: Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
Sent: 17 June 2025 01:53
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Steve Green < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Techniques for meeting WCAG SC 4.1.3 (Status Messages)
The SC specifically states the status is exposed by change in role or in a manner that does not require the status message to receive focus.
Aria-describedby, aria-labelledby, aria-label are designed to make associated content programmatically determinable when the particular element receives focus.
As such these cannot be used solely to satisfy SC 4.1.3 IMO.
Sailesh Panchang
Principal Accessibility Consultant
Email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
Deque Systems Inc | - Accessibility for Good | www.deque.com<;http://www.deque.com>;
On Mon, Jun 16, 2025 at 12:23 PM Steve Green via WebAIM-Forum < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
I have given this a great deal of thought, helped greatly by Adrian Roselli's article at https://adrianroselli.com/2023/04/exposing-field-errors.html. My conclusion is that the “aria-describedby” attribute is not suitable for use as a live region with respect to conformance with success criterion 4.1.3. I will therefore not open an issue on the WCAG repo at this stage.
For those who care about this arcane topic, the arguments for and against are:
For
* Section 4.8.1 of the W3C Core Accessibility API Mappings 1.2<https://www.w3.org/TR/core-aam-1.2/#mapping_events_state-change> specification states that changes in the value of the “aria-describedby” attribute must be exposed as an event via the accessibility API (which would trigger the live region). This is currently a draft specification.
* The technique works with NVDA screen reader and Chrome on Windows 11.
* The technique should work with other Chromium-based browsers such as Microsoft Edge, Opera and Samsung Internet.
Against
* This use of the “aria-describedby” attribute is not included in any of the Sufficient Techniques for success criterion 4.1.3.
* Section 5.8.1 of the W3C Core Accessibility API Mappings 1.1<https://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change> specification does not include the “aria-describedby” attribute. This is the current version of the specification. We do not know when v1.2 will be published or whether it will be modified before publication.
* The technique is unlikely to currently work with other browsers such as Firefox and Safari. We do not know if or when they will adopt the W3C Core AAM 1.2 specification.
* It is possible that the technique only works if the website automatically moves the focus to the form control that is in error.
* We have not tested the technique with any other Chromium-based browsers or any other assistive technologies. In 2023, Adrian Roselli tested this and some other techniques with a large number of browsers and assistive technologies. His results are in line with our expectations.
Steve