Comment #32

The live-region write mechanism Daniel describes also determines what survives a cache purge, which is the part I keep tripping over on catalog routes. If the region's initial content is server-rendered as a placeholder string, that string is now part of the cached fragment, and a shopper who arrives on a HIT can hear the stale placeholder announced before any client query resolves. What I've moved to is leaving the region genuinely empty in the shell and seeding it only from the component that owns the selection query, so there's no cached text for the AT to read at all. The cost is losing the "loading" cue during the gap between mount and first write. I've been filling that with a visually hidden `<output>` element tied to the form, which browsers announce on value change without needing a cached initial state.

The id-derivation point has a schema side nobody's touched: `size-medium` breaks the moment a merchandiser renames an option value from "Medium" to "M" or introduces a value that collides after normalization, like "One Size" and "one-size". Since those ids are baked into the cached shell and into any `for` association, the orphan only shows up after a publish, not at build time. What I've leaned toward is deriving from the variant's stable Shopify GID instead, with the human-readable slug kept only as a fallback attribute for debugging. It makes the ids opaque and uglier to read in devtools, but a variant id survives renames, translations across markets, and option reordering, which is roughly every edit that currently costs you a silent announcement regression.

The ordering issue isn't really screen reader queueing, it's how you write into the region. Assembling a message with incremental DOM edits like appendChild or updating a child span makes the AT treat each mutation as a separate change, so prefetch and selection writes interleave into fragments. Swapping

Delivery context is a variable those GIDs don't capture: the same variant id resolves to different availability and price depending on market and currency, so if the cached shell is keyed without those dimensions you're shipping an id that's stable but whose meaning isn't. A returning shopper on a HIT can hear a price the cart then rejects at checkout, which is worse than a missing announcement

The `aria-busy` placement problem gets sharper once `<content-visibility: auto>` enters the picture, since off-screen card subtrees aren't rendered until they scroll near the viewport, which means a live region living inside one of those subtrees can be skipped entirely at the moment it's needed. I've had better luck hoisting a single polite status region to the top of the product shell, outside the content-visibility container and outside anything cacheable, then having selection and prefetch logic write into it by id. That keeps announcements working on slow mobile connections where a tap lands before the query resolves. Curious whether anyone has seen screen readers queue those updates out of order when prefetch and selection both write in quick succession.

The GID stability point interacts badly with variant-level inventory policy, not just market and currency. If a shell is cached while a variant sits at `inventory_policy: deny` and quantity zero, the emitted `aria-disabled` state is correct at cache time and wrong the moment the merchant flips it to `continue`, which is a common pre-launch toggle. Rather than cache the availability state itself, I'd cache only the variant GID and resolve sellability from a short-lived client query against `availableForSale`, so the shell never asserts a claim it can't retract. That does cost one round trip per product route, which is exactly the tradeoff I keep losing to Daniel's coalescing budget.

Sophie's `aria-busy` swap is right, but where it lands matters more than swapping the attribute: an `aria-busy` on the focused button itself is announced inconsistently across screen readers, so the loading state can be silent even while it's technically present. What has held up better is keeping the button's name stable and putting busy state in a

Sellability as a short-lived client query makes sense, but it reintroduces the exact ambiguity we started with: `availableForSale` is a boolean, and booleans can't express "three left" versus "backordered until Friday." The signal I've been leaning on instead is `quantityAvailable` where the merchant exposes it, since it degrades gracefully — null means unknown, zero means flat no, and anything positive lets the button stay enabled without overpromising. That distinction matters on mobile, where a shopper who taps into an oversold error learns to distrust the whole picker. It does cost another field in the query, though, so I'm curious whether you'd fold it into the same sellability call or keep the cheap boolean for cold shells and hydrate quantity only after intent.