Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
ccd07fc to
b3866b9
Compare
PR Analysis Report
No new or modified components detected. Bundle Size Summary
Accessibility AuditStatus: No accessibility violations detected. Visual Regression23 of 446 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 3 more. Generated by PR Enrichment workflow | View full report |
There was a problem hiding this comment.
Approval is waiting on a maintainer spec decision, not on changes from you. The fix looks correct and is well covered by its new tests. No current Astryx spec covers TabList or TabMenu keyboard behavior, so a maintainer needs to provide or identify the spec claim that keys pressed inside a nested popup, such as an open TabMenu, belong to that popup, with Left/Right on a menu option keeping focus there. No code changes are requested right now; thanks for the clear write-up.
[Automated review]
User impact
A keyboard user opens a
TabMenu, moves to an option, and presses Left or Right. Focus leaves the still-open menu and lands on the outer tab strip. The next key acts on a tab or the menu trigger, not the option the user was choosing.Problem and solution fit
TabList. The menu's vertical focus handler leaves horizontal arrows alone, and the outeruseListFocushandles them as tab-strip navigation because it has no boundary configured.The fix gives the tab strip's existing focus hook a boundary, so a nested popup keeps its keys.
Expected behavior and authority
The WAI-ARIA APG menu pattern distinguishes a menu opened by a menu button from a menubar: Right Arrow does nothing on a leaf item when there is no menubar to move through.
TabMenuis a menu button with leafmenuitemradiooptions, not a menubar submenu. Its horizontal arrows must not become navigation in the surrounding tab strip.useListFocusalready documents and implementsboundarySelectorfor ignoring events owned by a nested list. The currentcomponent:TabListrecord governs edge compensation, not this keyboard behavior. No record changes.Smallest restoration
One option in
TabList.tsx:boundarySelector: '.astryx-tab-list, [popover]'. The selector names the common outer root, where the hook's ref lives;role="tablist"is on the inner strip. A key from the menu reaches its popover boundary first, while a key from the strip reaches its own root.The regression test presses both horizontal arrows on an open menu item and checks that focus stays there and the menu stays open. A companion jsdom test checks that a
role="tablist"inside a popover still navigates between its own tabs. A Core patch changeset accompanies them. This adds no API, default, visual change, or new key handling.Evidence
core-tablist--with-menu. Open More and focus Reports. Right Arrow moves focus to Home; Left Arrow, tested from Reports again, moves focus to More. The popover remains open in both cases.TabList.tsxat the focus assertion after Right Arrow. With the change, all 131 targeted tests pass, including that case, tab-strip navigation inside a popover, menu selection and dismissal, and the Tabs DOM accessibility contracts.Scope
Testing
Chromium checks above used the existing Storybook story against the pre-change source and this branch. WebKit and Firefox were not run.
The PR is draft because full local validation is not green.
pnpm lint:strictpassedcheck:repo, then reported 992 errors in the ignored local artifactassets/theme-runtime-lab.generated.js; no TabList lint errors were reported.pnpm test --maxWorkers=4reported two failures inapps/storybook/.storybook/story-tree.test.ts; the full run was then stopped and is not reported as passing. Those files are outside this diff.