Which focus-and-announcement strategy should an htmx search-results workflow use for screen reader users?

I'm designing a search filter that issues hx-get requests and swaps results into a container with hx-target, using hx-indicator for the loading state. The goal is for screen reader and keyboard users to perceive each update as reliably as sighted users do.

From the htmx documentation I can see the event lifecycle (htmx:beforeRequest, htmx:afterSwap) is hookable, but the library itself appears to ship no default focus management or announcement behavior after a swap — that decision is left entirely to the implementation. I'm unsure which combination is considered sound: moving focus into the swapped region, writing a status message into an aria-live="polite" region, setting aria-busy on the target while the request is in flight, or some mix of all three. Moving focus on every keystroke-driven filter seems disruptive, yet announcing without focus movement risks users never finding the new content.

Assume htmx 1.9.x; I will verify event names and swap options against the installed version.

Should focus move to the swapped container after htmx:afterSwap, or is a live-region announcement alone acceptable for repeated filter updates? Does aria-busy on the target actually get announced reliably across NVDA and VoiceOver? Is there any community-accepted pattern for handling hx-swap-oob updates accessibly?