Currently, every time we need to send feedback to assistive technology, developers should add an aria-live element to that specific task. This can lead to having a lot of aria-live elements. It can be avoided by creating a core library to be reused. 

During the course of MDL-84832, there has been significant input from Jun in the development for the core library:

An alternative approach would be to follow something similar to what the core/local/reactive/srlogger does, which creates an aria-live div on demand and updates its contents.

1: Create a SR-only live area JS module

I would copy/move the bulk of the core/local/reactive/srlogger code outside of the reactive namespace and into its own JS module. We already have a core/local/aria namespace (in lib/amd/src/local/aria) where we can put this module. This can be the equivalent of the live announcer module you created.

In terms of naming, "live announcer" may be a bit misleading. The JS module creates a visually hidden ARIA live region and provides a method for other components to update the live region's content. So, perhaps a good name for the module would be something like "SROnlyLiveArea" or "VisuallyHiddenLiveArea", which may be long, but clear enough for its purpose.

The live area module can then have an update() method that updates the contents of the live area. (So, basically, rename the updateAnnouncer() method to update()).

2: Create a module that performs the input event handling and calls the live area JS module.

We can also create a JS module in core/local/aria that performs input checks, such as the maximum length check. The liveannouncer_maxlength module you created can be renamed to a core/local/aria/inputchecks module, and move the maxlength-checking logic to its own function within the module, and call this in the handleInput method. This way, if we need to add more checks in the future, we can simply add more functions and then call them in the handleInputEvent method. I don't think we'll create a lot of these input checks, so there's no need to create separate JS modules for different input check types.

In terms of input event handling, we may want to ensure that the max length checking event only covers input characters. For example, if I press the Shift or Ctrl key by itself or any other non-input keys on the keyboard, I should not hear an announcement that the maximum number of characters has been reached.

3: Initialise the input checking module

Finally, we initialise the input checks in the init function of the theme_boost/aria JS module.

Optionally (or possibly as a separate issue), we can also modify the core/local/reactive/srlogger module to call the live area module.