Clarify expectations for live regions rendered with text already present

[0ddfell0w]

Live regions indicate that changes within the region should be communicated to assistive technology.

Is there an expectation that assistive technology register changes in live regions when
A) Live regions are present upon initial page load
or
B) Live regions are inserted with text already present within them

This question is motivated by issues in Firefox and JAWS/NVDA wherein announcements are only made if live regions are updated some time after the element is present in the DOM.

[pkra]

Adding this to milestone for ARIA 1.4 since the live region project is almost entirely overlapping.

[minorninth]

I'd love to make some incremental progress here, as I've seen this continue to frustrate developers.

I recently did some testing and I'd like to update the spec to reflect the current consensus implementation in major screen readers, specifically:

• Text that is already present in a live region when the page loads, or when the live region element first appears, is not announced
• Subsequent additions or changes to text in the live region are announced
• The exception is role="alert" - text inside an alert should be announced on page load or when the live region element appears.

The text for role=alert is already reasonably clear.

My proposal would be to add a couple of sentences to the text for each of the other live region roles, and to the description of the aria-live attribute, that says:

Assistive technology should only announce changes to a live region, not the initial contents of a live region on page load or when the live region element appears. To ensure content in a live region is announced, authors SHOULD create an empty and visible live region as early as possible (such as on page load), and then add content to the live region when it should be announced.

Where appropriate we could add: The exception is role=alert. While an alert is a live region, its contents are announced when the alert element appears on the page.

[MelSumner]

@minorninth I wonder if

Text that is already present in a live region when the page loads, or when the live region element first appears, is not announced

could be something more like

Text that is already present in a live region when the page loads is not announced outside of the normal reading out of the page content.

This would address two concerns:

1. if a live region appears after page load, I'd expect the contents to be read to me
2. I'd want the info to be read to me, if it exists, on page load

Once the text content is updated, then I would expect the regular amount of assertiveness.

Does this make sense or is it over-complicating things? WDYT?

[cookiecrook]

Perhaps the compromise is in the assertive value...

<!-- from the alert characteristics table -->
Default for <pref>aria-live</pref> is <code class="default">assertive</code>.

Which would account for the default alert behavior Dominic wanted ("The exception is role=alert.") but would not result in a role-specific exception.

And would also prevent the additional chattiness we're see when sites create a ton of non-assertive live regions like we're seeing on a popular site at the moment.

[minorninth]

@MelSumner I was hoping that whatever we specify is consistent with the behavior of the majority of existing browsers and screen readers. Right now the spec is ambiguous in many scenarios, so in disambiguating we should clarify the current consensus behavior. If we were to propose a change to behavior, that would break existing sites.

I like adding the text "outside of the normal reading out of the page content" or something along those lines. We don't want to imply that because something is in a live region that it wouldn't be read as part of the normal page content. The only question is whether it's announced without the user navigating to it.

However, you say "if a live region appears after page load, I'd expect the contents to be read to me" - this is not how live regions behave today. Making it behave that way would break things.

For the same reason, I don't think we should use assertive to trigger a live region announcing when it appears - that'd break things.

As motivation for the current consensus implementation (the live region does not announce when it appears, only when it changes), consider something like a list of meeting attendees. The author might want to show the attendees, and have subsequent changes to the list of attendees announced, without announcing each initial attendee.

[cookiecrook]

Yes, @minorninth helped me remember the alert exceptionalism is in part due to the alert notifications, separate from other live region types, regardless of their assertiveness. As called out in the the AAMs for alert and alertdialog only: "The user agent SHOULD fire a system alert event."

I agree with the rest of the comments that we should clarify ambiguities but without changing UA requirements for established patterns where the implementations agree. Treading especially cautiously since these notifications won't be testable in WPT for some time to come, so changing any expectations that require UAs break established web dev patterns would be detrimental.

[cookiecrook]

@MelSumner @minorninth @0ddfell0w Draft PR is #2116. Unless you have major feedback, I plan to change it to a non-draft PR before tomorrow's ARIA WG meeting.