Keyboard focus is left unpredictable after push_patch in Phoenix LiveView

Phoenix LiveView patches the DOM over a WebSocket connection instead of reloading the page, and patched content is not announced to assistive technology on its own. Documented guidance puts that burden on authors: mark dynamic regions with aria-live, as the generated core_components.ex flash component already does, and reach for phx-hook when declarative bindings fall short.

The unsettled piece is focus. After a push_patch or push_navigate, LiveView does not restore focus to a predictable element, so keyboard and screen-reader users can lose their place in the page. Community discussion treats this as an open design question rather than a documented default, and generated markup differs across Phoenix and LiveView versions, so any conclusion should be verified against the installed release — assumed here to be a Phoenix 1.7-era app.

The decision is framework-wide. A documented default would shape every generated app at once, while a per-app policy leaves focus work to each team via phx-hook.

• Should LiveView define a default focus target — the triggering element after push_patch, the new view's main heading after push_navigate — or is explicit per-app handling the intended long-term answer?
• Does focus behavior actually differ between push_patch and push_navigate today, and is that difference documented for the current release?