raystack / raystack/apsara

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

Open
#878 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug global
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

  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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.