Summary
Components built directly on Base UI primitives (Dialog, Select, Tabs, Checkbox, Switch, Tooltip) get keyboard nav, focus trap/restore, and roles for free and look solid. The gaps are in components with hand-rolled behavior.
Issues found
-
Command: disabled items are unreachable by keyboard. command-item.tsx:65-81 renders disabled items as a raw <div role='option' aria-disabled> outside the Autocomplete primitive, with an existing TODO acknowledging it's a workaround ("Fix this when Base UI fixes this issue"). This item isn't reachable by the primitive's own roving keyboard navigation.
-
Menu/ContextMenu bridge keyboard nav with a synthetic-event hack. menu/menu-content.tsx:60-96 (mirrored in context-menu/context-menu-content.tsx:61-92) calls dispatchKeyboardEvent(item, KEYCODES.ARROW_RIGHT/ESCAPE) against querySelectorAll('[role="option"]') to bridge two primitives. Fragile — depends on synthetic event dispatch working the same as real keyboard input.
-
DataView doesn't announce filter/result changes. data-view/components/search.tsx and ordering.tsx have no aria-live/aria-expanded when filter or result counts change. Screen reader users get no feedback when a filter narrows the list.
-
Missing :focus-visible rules in Dialog and Tooltip CSS. Confirmed zero matches for focus-visible in dialog/*.module.css or tooltip/*.module.css, vs. 52 matches across 29 other component .module.css files. May look fine today via inherited/default browser focus styling, but isn't explicit.
Suggested approach
Priority order: fix #1 first (keyboard-unreachable content is the most severe — a real WCAG failure), then #3 (DataView live regions), then #2 and #4.
Notes
Found via a components.build practices audit (accessibility dimension). Base-UI-backed primitives were not found to have equivalent issues — this is isolated to bespoke composite components.
Summary
Components built directly on Base UI primitives (Dialog, Select, Tabs, Checkbox, Switch, Tooltip) get keyboard nav, focus trap/restore, and roles for free and look solid. The gaps are in components with hand-rolled behavior.
Issues found
Command: disabled items are unreachable by keyboard.
command-item.tsx:65-81renders disabled items as a raw<div role='option' aria-disabled>outside the Autocomplete primitive, with an existing TODO acknowledging it's a workaround ("Fix this when Base UI fixes this issue"). This item isn't reachable by the primitive's own roving keyboard navigation.Menu/ContextMenu bridge keyboard nav with a synthetic-event hack.
menu/menu-content.tsx:60-96(mirrored incontext-menu/context-menu-content.tsx:61-92) callsdispatchKeyboardEvent(item, KEYCODES.ARROW_RIGHT/ESCAPE)againstquerySelectorAll('[role="option"]')to bridge two primitives. Fragile — depends on synthetic event dispatch working the same as real keyboard input.DataView doesn't announce filter/result changes.
data-view/components/search.tsxandordering.tsxhave noaria-live/aria-expandedwhen filter or result counts change. Screen reader users get no feedback when a filter narrows the list.Missing
:focus-visiblerules in Dialog and Tooltip CSS. Confirmed zero matches forfocus-visibleindialog/*.module.cssortooltip/*.module.css, vs. 52 matches across 29 other component.module.cssfiles. May look fine today via inherited/default browser focus styling, but isn't explicit.Suggested approach
Priority order: fix #1 first (keyboard-unreachable content is the most severe — a real WCAG failure), then #3 (DataView live regions), then #2 and #4.
Notes
Found via a components.build practices audit (accessibility dimension). Base-UI-backed primitives were not found to have equivalent issues — this is isolated to bespoke composite components.