Accessibility rough edges in custom (non-Base-UI) components

Inizia da command-item.tsx:65-81 per capire perché le opzioni disabilitate restano escluse dalla navigazione da tastiera di Autocomplete. Poi esamina data-view/components/search.tsx, ordering.tsx, menu/menu-content.tsx, context-menu/context-menu-content.tsx e i moduli CSS di dialog e tooltip. Il lavoro è completato quando i componenti personalizzati elencati forniscono accesso da tastiera, annunci di filtri/risultati, un comportamento robusto del bridge e uno stile focus-visible esplicito.

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

1. 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.

2. 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.

3. 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.

4. 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.