Accessibility rough edges in custom (non-Base-UI) components
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 70
- Forks
- 13
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 8
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with command-item.tsx:65-81 to understand why disabled options fall outside Autocomplete keyboard navigation. Then inspect data-view/components/search.tsx, ordering.tsx, menu/menu-content.tsx, context-menu/context-menu-content.tsx, and the dialog and tooltip CSS modules. Done means the listed bespoke components provide keyboard access, filter/result announcements, robust bridge behavior, and explicit focus-visible styling.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- accessibility, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100