Conversation
Phase 1 of focus management migration (FOCUS-MANAGEMENT-PROPOSAL.md §5). - Add get-active-element.ts: shadow DOM-aware activeElement traversal - Add focusable-selectors.ts: standard HTML focusable/tabbable selectors (removes 1st-gen [focusable] attribute workaround) - Refactor hasVisibleFocusInTree() to use getActiveElement(), removing dead ancestor-chain code and legacy .focus-visible polyfill fallback - Export new utilities from utils/index.ts
Phase 2 of focus management migration (FOCUS-MANAGEMENT-PROPOSAL.md §5). Consolidates 1st-gen FocusGroupController + RovingTabindexController into a single, self-contained reactive controller. Key changes from 1st-gen: - Flat single-file architecture (no base class inheritance) - MutationObserver uses attributeFilter for disabled/aria-disabled only - Listener scope defaults to host.renderRoot for shadow DOM encapsulation - Removes redundant click handler (focusin covers click-to-focus) - Removes virtualization offset (deferred until needed) - Simplified tabindex management (direct tabIndex set, no requestUpdate)
Phase 3 of focus management migration (FOCUS-MANAGEMENT-PROPOSAL.md §5). Extracts disabled state handling from 1st-gen Focusable base class into a standalone, composable mixin. Uses aria-disabled on the host for screen reader discoverability rather than the native disabled attribute. Manages tabindex removal/restoration and blurs active element on disable.
…onents into nikkimk/rti-demo
…onents into nikkimk/rti-demo
|
📚 Branch Preview Links🔍 First Generation Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
2 participants
Description
Prefer native focusgroup when 'focusgroup' in HTMLElement.prototype (or agreed feature-detection) is trueProvide a polyfill that mirrors the proposed semantics closely enough for SWC components to use one APIMotivation and context
Propose a next-generation approach for composite widget keyboard navigation (roving tabindex and related focus management) across Spectrum Web Components. The goal is to align with the emerging focusgroup HTML attribute as a declarative, platform-native solution where possible, and to ship a small, well-tested polyfill where browsers do not yet implement it.
Primary reference: Request for developer feedback: focusgroup (Chromium / Open UI; behavior tokens, inline / block / wrap / nomemory, focusgroupstart, role inference, shadow DOM behavior, feature detection).
Today, many components duplicate roving-tabindex logic (accordion, toolbar, tabs, menus, listbox-like lists, segmented controls, etc.). Centralizing on focusgroup plus a polyfill should reduce bugs, improve consistency, and shrink maintenance surface—while preserving accessibility expectations from the WAI-ARIA APG.
Grid-oriented navigation (two-dimensional roving across rows and columns, home/end, page up/down where applicable) is not fully specified as a single focusgroup behavior token in the current public proposal. This ticket should therefore treat grid as an explicit extension in the polyfill (and/or layered pattern using nested focusgroups + documented rules), mapped to the APG grid pattern—not assumed to be “free” from the native attribute alone until the standard catches up.
Related issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
Device review