Live regions and input values

[giacomo-petri]

Description:
The values of the aria-relevant attribute are:

Value	Description
additions	Element nodes are added to the accessibility tree within the live region.
additions text (default)	Equivalent to the combination of values, "additions text".
all	Equivalent to the combination of all values, "additions removals text".
removals	Text content, a text alternative, or an element node within the live region is removed from the accessibility tree.
text	Text content or a text alternative is added to any descendant in the accessibility tree of the live region.

<label for="qty">Quantity</label>
<button aria-label="decrease quantity" disabled>-</button>
<input type="number" value="0" aria-live="assertive">
<button aria-label="increase quantity">+</button>

Consider the provided example with a dynamic input whose value changes based on user interactions. Reading the documentation, it seems that ARIA does not currently provide specific guidance on how to handle changing values. The specification neither instructs authors on managing this scenario nor outlines how UA/AT should handle it.

While potential workarounds involve adding another node within the DOM, utilizing a live region, and communicating the message, the existing example is straightforward to implement and already includes all the necessary components for user communication.

The question arises: should we consider adding a note to clarify the expected behavior for these scenarios? Alternatively, could the solution involve introducing a new value for the aria-relevant property, such as aria-relevant="value"?

[MarioBatusic]

To have aria-relevant="value" would be important, then changing a value - as in the examle above, where an is a live region, is neither a text nor an dditional child node in the parent element.
Also a guidance at least for devs would be very important based on the current live region processing by the screen readers.

[smhigley]

As a somewhat different take on this scenario, it might be best to avoid adding new features to live region attributes, but there might be some changes we can add to reduce the harm of adding aria-live to editable inputs.

One possibility could be a Core AAM addition that specifies that live regions should not be fired on focused elements that accept user input (so, input elements of type text, number, email, number, password, search, tel, date, and time, and contenteditable regions)

[spectranaut]

Discussed briefly in triage at the last ARIA meeting: https://www.w3.org/2024/02/08-aria-minutes#t04