WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Steve Green
Date: Jun 17, 2025 12:33AM

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 REMOVED> >
Sent: 17 June 2025 01:53
To: WebAIM Discussion List < <EMAIL REMOVED> >
Cc: Steve Green < <EMAIL 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 REMOVED> <mailto: <EMAIL 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 REMOVED> <mailto: <EMAIL 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