Manuel MatuzovićAs you know, browsers and screen readers receive updates frequently. That's why it's important that you reevaluate the best practices you've been following for years every now and then and check if they still apply. Often, things that were true 5 years ago aren't true today.
Georgiana@matuzo An example for me is that in 2023 aria-live="off" silenced the aria-live, but now aria-live="off" works correctly and speaks the messages if you are in the area. But I still don't know if it was a screenreaders problem or a browsers problem because it didn't work at all.
Adrian Roselli, pH0@Georgiana_FH
Do you mean `off`?
Because if so, you might have those behaviors backward?
Asking because I am curious of the use case where you are using that value versus removing the property.
Accessible Rich Internet Applications (WAI-ARIA) 1.3
Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup. This version adds features new since WAI-ARIA 1.1 [wai-aria-1.1] to improve interoperability with assistive technologies to form a more consistent accessibility model for [HTML] and [SVG2]. This specification complements both [HTML] and [SVG2].
@aardrian @matuzo Sorry, I'll edit it, yes, it's off.
Oh, you're right. I'm really confused. No, I don't have the behavior reversed. I know that in 2023 I was working on a carousel that only sent aria-live messages when you had focus in the region, and at that time aria-live="off" was supposed to be for that, but it wasn't working; it was actually deactivating the regions. +
@aardrian @matuzo
Recently, less than six months ago, a client was using it for something similar—I don't remember if it was a carousel or news updates, or something like that—and it was working as I described, only sending the messages when the region was selected. I remember talking to my colleagues about it and saying, "Oh, look, great, they've fixed it," I must have the messages somewhere. +
Recently, less than six months ago, a client was using it for something similar—I don't remember if it was a carousel or news updates, or something like that—and it was working as I described, only sending the messages when the region was selected. I remember talking to my colleagues about it and saying, "Oh, look, great, they've fixed it," I must have the messages somewhere. +
@Georgiana_FH I haven’t tested support for `off` (because typically you don't want to toggle a region on and off owing to how platform accessibility APIs recognize it) but at the very least you can use this to confirm some of your browser pairings: https://adrianroselli.com/2026/01/live-region-support.html
Live Region Support
This post does not discuss whether live regions are good, nor is it a post about the best way to use them. This post only covers how they are exposed to the audience who experiences them — screen reader users. Written by a non-screen-reader user. If you’re here because your…
@aardrian @matuzo Thanks. I've been talking with @inovegil and I think I've been misunderstanding the behavior all the time because I was applying it to regions, not elements. I understand that if I have an element and its accessible name changes, it doesn't matter if it doesn't have it, since that's the default behavior, (now and before). But I understood it to apply to regions, so that if you put focus on a region, the screen reader would only read the changes when you're inside it.
@Georgiana_FH
A live region would be announced regardless of where screen reader focus is. Ideally, a live region would never get focus (nor get the screen reader cursor).
An element’s accessible name changing is a different challenge (and inconsistently exposed).
From your description, I have too many questions to try to sort it out in Masto posts, but you may want to read this post for broader live region use:
https://tetralogical.com/blog/2024/05/01/why-are-my-live-regions-not-working/
Why are my live regions not working? - TetraLogical
Live regions have a reputation for being "flaky" and inconsistent. While this can be attributed in part to shortcomings in current implementations, the problem can also be caused by developers misunderstanding how live regions are intended to work.
Iván Novegil@aardrian @matuzo @Georgiana_FH she apparently tested at some point and noticed that aria-live="off" and no aria-live led to different results, but since "off" is the value defined as the default this should not happen, as you say. So far I wasn’t able to reproduce, but I wouldn’t say it’s not reproducible, despite it shouldn’ you know that sometimes the spec and the actual implementation speak different languages.
@inovegil
Good to know. I may update my tests to see how `off` is exposed. I’m so used to doing it without, that I forget others use it. So that’s a limitation of my imagination.
If I find issues, then bug filing!
FWIW, I’m on the ARIA WG, hence my questions.
@aardrian @matuzo @Georgiana_FH her idea for "off" was that changes on the region where announced, but only when the focus is inside that region. The fact is that the definition in ARIA 1.2 is not very explanatory and that such a feature, although currently seems not to exist, would help when dealing with separate contexts within a webpage such as a chat window, where perhaps message anouncements are only relevant when the user is inside it. Could be something interesting to think about...
@inovegil The point of a live region is to announce when the user’s focus (programmatic or virtual cursor) is elsewhere.
If the message is only relevant when the user is already in it, then a live region is the wrong tool.
Typically the messages in a chat would be a different node (as the user might keep focus on the input).
Some more context:
https://smhigley.github.io/slides/notification-lives/#/20
@aardrian @Georgiana_FH fair, probably as I posed it doesn’t make a lot of sense. The thing is precisely what you say, the information may be relevant only when the user is focusing a specific control, other than the live region itself, such as the chat input field or the previous/next buttons of a carousel. There are other approaches for sure, but I wouldn’t find it useless to think about mechanisms for refining the propagation of aria-live notifications.