Bug: Settings Menu Sets ARIA-Hidden on a Submenu Page That Still Holds Focus ("Blocked aria-hidden … descendant retained focus")

[stow1x]

Version: @videojs/html 10.0.0-rc.2 (not reproducible on 10.0.0-beta.31)
Browser: Chrome 151 (macOS)

Steps to reproduce

Stock default video skin, no custom code (CDN build @videojs/cdn@10.0.0-rc.2: video.js + video.css + media/hlsjs-video.js):

<video-player>
  <video-skin>
    <hlsjs-video src="https://demo.unified-streaming.com/k8s/features/stable/video/tears-of-steel/tears-of-steel-multi-lang.ism/.m3u8" muted playsinline></hlsjs-video>
  </video-skin>
</video-player>

1. Open Settings.
2. Open Speed.
3. Click 1.5× (same with a Back row, and with the Audio / Captions pages).

Expected

The submenu closes and focus returns to the parent row without an accessibility warning.

Actual

Chrome logs:

Blocked aria-hidden on an element because its descendant retained focus. The focus must not be hidden from assistive technology users. …
Element with focus: <media-menu-radio-item.media-menu-radio-item>
Ancestor with aria-hidden: <media-menu-content.media-menu-content#…-content>

Focus does end up on the parent row, but for that moment the focused item is inside an aria-hidden page, so assistive tech is told the focused element is hidden.

Cause

setInactive() in @videojs/core dist/dev/dom/ui/menu/popup.js sets aria-hidden="true" and inert on the page that is becoming inactive while focus is still inside it; focus is moved to the parent afterwards. Moving focus to the parent (or at least out of the page) before setInactive(page, true) — or relying on inert alone, which already removes the subtree from the accessibility tree and blurs focus — would avoid it.

Notes

Not present in 10.0.0-beta.31 with the same steps (the page-based menu arrived after beta.31).

[github-actions]

Planning recommendation: add this to project #7 and the GA milestone, and treat it as P1 (recommendation only): it is a regression in the release candidate that produces an assistive-technology warning in the stock settings menu. No active epic is a clear fit.

This is related to, but not a duplicate of, #2215: that closed issue covered keyboard navigation getting stuck after returning from a submenu. The shared popup coordinator currently applies aria-hidden/inert to an exiting submenu before focus restoration; plan one regression test for that ordering in the core coordinator and integration coverage for both HTML and React menu renderers.

[javierarams]

Confirmed live in a real browser using sandbox.

The exact warning fires as reported:

Blocked aria-hidden on an element because its descendant retained focus. The focus must not be hidden from assistive technology users. Avoid using aria-hidden on a focused element or its ancestor. Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden.
Element with focus: <media-menu-radio-item.media-menu-radio-item>
Ancestor with aria-hidden: <media-menu-content.media-menu-content#vjs-0HL7I0RE-0-content> <media-menu-content class=​"media-menu-content" id=​"vjs-0HL7I0RE-0-content" role=​"menu" tabindex=​"-1" data-submenu style hidden>​…​</media-menu-content>​custom-element

I'll bring this to the team so we can decide on next steps. Thanks for the report!