`marquee` and `timer` listed as live region roles but have intrinsic `aria-live="off"`

[patrickhlauke]

In https://www.w3.org/TR/wai-aria-1.3/#live_region_roles marquee and timer are listed as live region roles. However, when then following through to their definitions, it states:

Elements with the role marquee have an implicit aria-live value of off.

https://www.w3.org/TR/wai-aria-1.3/#marquee

Elements with the role timer have an implicit aria-live value of off.

https://www.w3.org/TR/wai-aria-1.3/#timer

As aria-live="off" is the default for all elements, isn't this contradictory? I'd have expected that roles listed as being live regions would have an implicit value of either polite or assertive.

Unless there's some extra "magic" here that is not explained - "they're off but still behave differently in some unspecified way compared to other elements"? But then that aspect should be clarified explicitly... looking at https://www.w3.org/TR/wai-aria-1.3/#aria-live there's a lot of prose explaining assertive and polite, but for off you only get the short definition in the table

Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region.

But again, if this is the default, I would not expect a difference in an element that either has no aria-live attribute at all, and one that has aria-live="off".

[JAWS-test]

As it is currently defined, it does not make sense. However, the idea behind this could have been: there are live regions whose automatic output by the screen reader would generally be disruptive and unnecessary (as would indeed be the case with marquee and timer), but which could be activated permanently or temporarily by a specific screen reader command. I.e. if I want to know how much time I have left until logout, I press INS+[key for live regions] and hear the last updated value in live regions with aria-live=off once. If I press INS+CTRL+[Key for live regions], I activate the output of aria-live=off permanently.

See: https://github.com/FreedomScientific/standards-support/issues/282

[JAWS-test]

Another reason for the role could be that although I do not get the changes automatically, when I reach the element with the screen reader, I hear the element role and thus know that something changes here from time to time - a reference to areas with dynamic changes and the type of change

[patrickhlauke]

the idea behind this could have been

again, while I appreciate your thoughts on this @JAWS-test ... the idea of me filing the issue here is not to speculate ("what may the spec writers have meant by this?"), but to ask them directly...

[JAWS-test]

@patrickhlauke My answer is not intended to question your ticket (which I support: "As it is currently defined, it does not make sense"), but to consider how the ticket can be resolved. The roles can be deprecated or better specified or a difference between a new aria-live=silent and aria-live=off can be introduced

[spectranaut]

Discussed today during new issue triage: https://github.com/w3c/aria/issues/2144

[patrickhlauke]

@spectranaut was that meant to link to the actual discussion? currently just points back to itself here, and not sure how https://github.com/w3c/core-aam/issues/224 that also references this issue here relates to it /cc @scottaohara

[scottaohara]

i think that was just a mistake copy/paste. short summary is that there is some work to clarify expectations here. here are the minutes, but it was just discussed at a high level in the largely issue triage meeting we had today - https://www.w3.org/2024/03/14-aria-minutes.html

[MarioBatusic]

The value "off" is really nonsensical. Maybe we could introduce the value "silent" and use it as the default for theese roles. So we had in the characteristics table of "aria-live" instead for "off" the description for "silent" stated identically as now for "off":

Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region.

Additionally, screen readers could offer an option to mute / unmute silent live regions, so the user had not to search for them in the page.

[patrickhlauke]

if the idea indeed is that "absence of aria-live attribute" and "aria-live="off"" are two distinct separate things (?), then agree that "off" is a very misleading/confusing value.

if the idea is that aria-live="off" does indeed mean "only announced when the user is focused on that region", then silent doesn't sound that much clearer either. without wanting to bike-shed too much, perhaps more aria-live="focused" or similar may better convey what is actually meant to go on (assuming I understood the intended nuances right here).

[smhigley]

1104 has some relevant discussion related to this issue

[cookiecrook]

Agreed that silent is not clear... focused is closer but ignores two things:

1. there's no clear distinction of AT focus vs KB focus
2. there's no allowance in the name for the "watched" scenario... e.g. SR user marks it as "tell me when this changes" and that should work as expected in combination with aria-relevant and aria-atomic

[patrickhlauke]

again, at the risk of bikeshedding too much here... aria-live="local" ?

also, judging by this discussion here, am I now to understand that my assumption here is indeed correct?

"absence of aria-live attribute" and "aria-live="off"" are two distinct separate things

and if so, this definitely needs to be clearly documented - like a big important boxout/note that says aria-live="off" is not the same as not having aria-live at all" (or words to that effect)

and then separately come up with a better name, and further clarification for, whatever off may be/become

[pkra]

Discussed on today's call https://www.w3.org/2024/03/28-aria-minutes.html#t06

[patrickhlauke]

From the minutes

mattking: do we need to define undefined?

jamesn: I'm not sure. … spec says "off" is the default.

and this, as well, is likely part of the confusion for developers. saying some value is the default seems to indicate "so even if you leave out the attribute, that's the assumed default" ... but i assume the "default" here is more "if you just add aria-live with no value, it defaults to "off")

[cookiecrook]

ARIA spec for aria-live currently says:

off (default) Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region.

…but that means we're missing an undefined value that would be the actual missing value default or invalid value default.

[cookiecrook]

Simplified test case here. https://bug-271841-attachments.webkit.org/attachment.cgi?id=470641

[cookiecrook]

@patrickhlauke wrote:

separately come up with a better name

yeah, discussion was that "off" is too confusing for authors given the original intention... spec needs to add 1. an undefined default, and 2. probably a more clear synonym for "off" (perhaps "local" as patrick and others suggested, but it's a fairly technical name that may still be unclear to some authors)

[spectranaut]

Discussed briefly in yesterday's meeting: https://www.w3.org/2024/04/04-aria-minutes#t08

[patrickhlauke]

https://www.w3.org/2024/04/04-aria-minutes#t06

[patrickhlauke]

dropping this here just for reference, but ... a recent article making the rounds that also misunderstands what aria-live="off" means https://scribe.rip/@askParamSingh/exploring-the-power-of-aria-live-attribute-in-web-accessibility-f80e6d110ed4#b1a2

aria-live=”off”: By default, it’s set to off. This value indicates that changes to the content within the region should not be announced by assistive technologies.

also, just spotted the MDN pages for live regions, that include the same misunderstanding https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions#live_regions

As aria-live="off" is the assumed default for elements, it should not be necessary to set this explicitly, unless you're trying to suppress the announcement of elements which have an implicit live region role (such as role="alert").

So it seems this misunderstanding is quite pervasive (unsurprisingly)