New rule: 'Status text update has `aria-live` property'

[ajanec01]

This is the very first go at the applicability, expectation and assumption section for a new rule, 'Status text update has aria-live property'

Blocked: waiting for decision on how to handle test instructions

[Jym77]

I think it makes sense. Some comments on the structure (there are also some nitpicky typos and similar but let's leave them for later).

• The other rules using "change in content" are effectively triggering the even causing the changes, not the "result" of the change. Especially, the definition of "change" doesn't really tell which element or text node is changing (it's about rendered pixels), which makes this connection difficult 😞
• This gets hairier because you want (in the examples) both cases where the content (inner text) changes and where the element is created from the void.
• The first expectation is a bit weird in trying to look at other test targets. Essentially, at expectation level only one target is known (well, not exactly, but that the idea).

I think we can also focus on accessible changes (and ignore the visible ones). That is, if some text appears but as part of a aria-hidden element, the lack of aria-live is not an issue. Since the existing definition of changes already has an item for changes in the accessibility tree, that should be doable.

For example, we could target either the node that changes or appears, or the parent of the node that disappears, and requires that it has an ancestor with the correct aria-live.

[ajanec01]

Good stuff. I was not sure about the change in content definition but it seemed to have fitted in without writing another definition. To summarize, your recommendation is to:

• Split the rule into two rules, one that is testing innerText changes and another rule to test elements created from the void?
• Make sure that the test target and its descendants are included in the accessibility tree?

As for your comment about the 1st expectation, I was trying to take into consideration cases where the text changes but on its own does not provide enough context. In those situations, it's better to add a visually hidden text that has aria-live. I'm not sure how else to describe it. There is certainly a definition needed there.

[Jym77]

To summarize, your recommendation is to:

• Split the rule into two rules, one that is testing innerText changes and another rule to test elements created from the void?
• Make sure that the test target and its descendants are included in the accessibility tree?

I think most of the rule can switch to the accessibility tree since aria-live only makes sense there. I'm not sure splitting the rule is needed, but the rule could trigger nodes in the accessibility that appear, disappear, or are modified (or maybe events that causes these change, to stay closer to the other "change" rules). That can maybe be done in a single rule. It's also easier to trigger the events than the content that appear because the content is not always here, so it's unclear what it means as a test target when it's not here… (that's discussions with had on the other changes rules).