Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#878 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
react, typescript
Domain
accessibility, frontend

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.

Description

bug global

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.

Dominant language
TypeScript
Stars
70
Forks
13
Avg merge
8d 20h
Merged PRs (30d)
17

Getting set up

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.

More from raystack/apsara

All issues in raystack/apsara

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.