Storefront UI's accessible defaults vs custom Nuxt templates: where should WCAG conformance live in a Vue Storefront build?

We are planning the frontend architecture for a Vue Storefront (Alokai) storefront and need to decide where accessibility responsibility should sit. The documented Storefront UI library builds components on accessibility-focused primitives, with keyboard navigation and ARIA attributes handled in modals, dropdowns, and accordions. The alternative is fully custom Nuxt templates, which give us design freedom but shift all WCAG responsibility — focus management, aria-live regions for asynchronous cart updates — onto our own implementation.

The constraint is the user-facing workflow, not isolated components. Add-to-cart and checkout state updates happen asynchronously, and as far as I can tell the core composables do not guarantee accessible announcements of those updates; they must be wired in the UI layer. Focus management on route changes is another documented SPA requirement that core does not appear to solve automatically. There is also a version wrinkle: Storefront UI v2 moved to a headless/Tailwind approach, so behavior differs from v1 and guidance must be pinned to the installed version.

So the unresolved decision is architectural: enforce conformance centrally at the composable/integration layer, or leave it to each storefront's UI implementation?

Assume a current Storefront UI v2 setup; I will verify with keyboard-only and screen-reader testing.

1. Does adopting Storefront UI meaningfully reduce workflow-level WCAG gaps, or only component-level ones?
2. Is there a documented pattern for aria-live announcements of async cart/checkout updates?
3. Who should own focus management on route changes — the integration layer or the theme?