[Bug Report][4.1.9] a11y: VMenu and VSelect/VAutocomplete/VCombobox reference an aria-controls/aria-owns id absent from the document while closed

Environment

Vuetify Version: 4.1.9
Vue Version: 3.5.38
Browsers: Chrome
OS: Linux

Steps to reproduce

Render a closed select or menu and inspect the served or hydrated DOM — no interaction needed, the defect is the closed state:

<v-select :items="['a', 'b']" label="Sort by" />

<v-menu>
  <template #activator="{ props }">
    <v-btn v-bind="props" text="Open" />
  </template>
  <v-list :items="['a']" />
</v-menu>

Run the page through the W3C validator (https://validator.w3.org/nu) or axe.

Expected Behavior

ARIA id references resolve, or are not emitted. The APG combobox pattern is explicit that the reference is only needed while the popup is up:

Note that aria-controls only needs to be set when the popup is visible. However, it is valid to reference an element that is not visible.

Referencing a hidden element is valid — referencing an id that is not in the document is not. In the menu button pattern, aria-controls is optional altogether.

Actual Behavior

The references are emitted unconditionally:

• VMenu.tsx — the activatorProps computed puts 'aria-controls': id.value, 'aria-owns': id.value on the activator.
• composables/menuActivator.ts — ariaControls = toRef(() => menuId.value), rendered as aria-controls on the input of VSelect, VAutocomplete and VCombobox.

But the element carrying that id only exists while the overlay has content: useLazy's hasContent is isBooted || eager || active, and onAfterLeave resets isBooted when not eager. So before the first open — and again after every close — the id is absent from the document, and every closed select/menu on the page fails validation:

The aria-controls attribute must point to an element in the same document.

(severity: error, one per attribute per closed select/menu; axe reports the same as aria-valid-attr-value. European accessibility audits — RGAA / EN 301 549 — flag each occurrence.)

Prior reports

• #19250 reported exactly this (axe flagging aria-owns="v-menu-759" on the activator) and was closed as a duplicate of #19054 — but #19054 only gave the id to the open menu. The closed state was never addressed.
• #22540 (open) reports that aria-owns on the activator breaks VoiceOver's announcement of menu item labels — one more reason not to advertise it while nothing is open.

Suggested fix

Emit the references only while the popup is open, which is the APG-documented pattern:

 // composables/menuActivator.ts
-  const ariaControls = toRef(() => menuId.value)
+  const ariaControls = toRef(() => toValue(isOpen) ? menuId.value : undefined)

 // VMenu.tsx
-        'aria-controls': id.value,
-        'aria-owns': id.value,
+        'aria-controls': isActive.value ? id.value : undefined,
+        'aria-owns': isActive.value ? id.value : undefined,

One existing test pins the current behaviour and would need its closed-state assertion moved after the open: VSelect.spec.browser.tsx › "should have reactive accessibility attributes" asserts aria-controls while expanded: false — i.e. it asserts the dangling reference.

VTooltip has the same shape ('aria-describedby': id.value unconditional while the tooltip content is unmounted) — happy to cover it in the same PR or leave it for a follow-up.

Our current userland workaround is eager defaults on the four components so the overlay stays mounted and the ids always resolve — viable because the lists are virtualised, but it mounts overlays nobody may ever open.

Happy to open a PR if this approach sounds right.

Start in composables/menuActivator.ts and VMenu.tsx, then read the closed-state coverage in VSelect.spec.browser.tsx, especially “should have reactive accessibility attributes.” Reproduce the closed VSelect or VMenu case with the W3C validator or axe, and verify that references resolve when open and are absent or valid when closed. VTooltip is noted as a possible follow-up, not required scope.