I'll be joining this effort, commenting here to add myself to the primary contact list: Jacques Newman (@janewman), Microsoft.

Hi folks, thanks for this review request and thank you for being patient with us as we work through a review.

We agree that 'offscreen' live regions aren't serving their purpose well, and on there being plenty of genuine use cases for visible live regions.

Overall we're happy with this design but do have some questions:

1. Do you foresee this somehow being extended to support earcons (possibly with text fallbacks) in future?
2. What implications would that have for the function signature?
3. In the explainer you mention:

A previous version of this explainer included an interrupt property (now described below). It seems unlikely that any implementers will include this property in their initial implementation

Why is that?

These aren't blockers and we're happy to mark this with a satisfied resolution

Hi Lola,

Thanks for helping to move this along. Let me know if you have any follow-up questions or asks for clarification.

1. Do you foresee this somehow being extended to support earcons (possibly with text fallbacks) in future? The Proposal - Type section of the explainer provides more details, but we are considering an optional type parameter that will allow for further customization of the notification experience, and this type could be used by screen readers to implement earcons.

2. What implications would that have for the function signature? This type is an optional second parameter with a reasonable default value, so there will be no need for authors to adjust existing implementations unless they would like to update to include this additional context. Alternatively, the type may be expressed in an object form with property type.

// Notify of a long-running async task starting and ending  
document.ariaNotify( 
    "Uploading file untitled-1 to the cloud.", 
    "task-progress-started" );  
// ...  
myfile.asyncFileUpload().then( () => {  
    document.ariaNotify( "File untitled-1 uploaded.", {  
         type: "task-progress-finished" } );  
});  

This has already been implemented in chromium and is available in both the v1 and v2 implementations, so this will be ready for testing once we unblock AT support and have confirmed that this can be added on seamlessly with the existing API and shipped progressively without any impact to compatibility. Here is where we are discussing with the working group to better understand the right structure for type: [AriaNotify] Should notificationId be a non-localized string? Is notificationId needed at all? · Issue #2330 · w3c/aria

3. In the explainer you mention: A previous version of this explainer included an interrupt property (now described below). It seems unlikely that any implementers will include this property in their initial implementation. Why is that?

Other than UIA, no other platform API supports an interrupt in their notification API, and while UIA technically supports interrupt, not in the way that we intend to specify it. We are working with them to build a proof of concept.