#7519·ariakit

Keep borderless Ariakit UI folder tab selection visible in forced colors

Author: diegohazCreated Sep 13, 2026Updated Sep 13, 2026
Labelsfeaturea11yui

Context

Found during review of #7500. The shipped Edgeless Tabs example uses <Tabs $border={false}>, default folder tabs, and no glider. Its selected tab relies on its fill to distinguish it from the other tabs.

Confirmed problem

This is pre-existing on main at 2a77466, verified independently in an isolated worktree. It also reproduces on #7500 at e812d66.

In Chromium 153 with forced-colors emulation, the selected tab has the same visible background as the page. The other tabs are transparent. All tab borders remain 0px, box-shadow is none, and outline-style is none after focus leaves the tab. The text has the same weight and color, with no selected decoration. Selection still updates aria-selected; the visual mark is missing.

The root deliberately publishes --border-width: 0px. Default folder tabs inherit that edge through $border: "inherit". This is a selected-state color problem in an explicitly edgeless composition.

Reproduction

  1. Open /react/previews/ariakit-ui-tabs/ and find Edgeless.
  2. Click Usage, then click the Edgeless heading to remove focus from the tab. With normal colors, the folder fill marks Usage.
  3. Enable page.emulateMedia({ forcedColors: "active", colorScheme: "light" }) in Chromium. The selected fill blends into the page.
  4. Click Code, then the heading. Selection changes, but no selected mark remains.

The same loss occurs with the dark color scheme. These checks use browser emulation on macOS, not a native Windows session. In stock Firefox 152 emulation, the selected native button retains a gray fill, rgb(233, 233, 237), so the reported loss was not reproduced there. A fix should cover both engines without removing the indication Firefox retains.

Why #7500 can finish without this

#7500 translates drawn ring edges to real borders and supplies an implicit edge for filled controls and gliders. This composition explicitly disables its inherited frame edge and has no glider. Its folder selection styles are unchanged by that PR. Preserving positive frame widths and implicit glider boundaries does not require a new selected-state treatment for a zero-width folder.

The PR description's broad reference to borderless Tabs selection described its flat and bevel glider fix. That wording is being clarified to identify the actual composition. This issue tracks the separate folder selected-state behavior.

Expected outcome

  • The selected default folder tab remains visually distinct in forced colors with <Tabs $border={false}>, including after keyboard focus moves away.
  • Preserve the edgeless normal-color appearance, correct aria-selected, keyboard focus indication, and the selected folder's relationship to its panel.
  • Add a targeted regression using the existing Edgeless sandbox in Chrome and Firefox, in both color schemes. Confirm that the selected mark follows a changed selection.

Evidence

The screenshots show the same selected Usage tab on the verified main revision, after focus leaves it.

Usage selected with a visible folder fill in normal light colors

Usage remains selected but has no visible mark in Chromium forced light colors

The recording shows selection changing, focus leaving the tab, and the missing mark in both forced-color palettes. Normal colors restore the fill.

https://github.com/user-attachments/assets/716ce17d-5f9b-4635-9b4b-b6b235d9f8d6