Accessible components for dense financial interfaces

Components

• DialogModals and confirmations on the native <dialog>, with focus returned and a safe default for destructive actions.
• TabsThe APG tabs pattern with automatic or manual activation, and panels anywhere on the page.
• Segmented controlRadio-group semantics that look like buttons; form-associated through ElementInternals.
• Data tableA real table for dense numbers: grouped headers, sticky columns, announced sorting.

Principles

• Semantic HTML first; ARIA only to fill gaps. A native <dialog>, a real <table>, form participation through ElementInternals. ARIA is added where HTML has no element for the job (tabs, radio groups that look like buttons).
• Keyboard parity. Everything a mouse can do, a keyboard can — following the ARIA Authoring Practices keyboard models, tested in a real browser.
• Never colour alone. Up/down, selected, at-the-money: each also has text, shape or an icon.
• Tokens that are tested, not hoped. Contrast is computed against real backdrops; a failing pair fails the build.
• Respect the user's settings. Reduced motion, increased contrast, reduced transparency and Windows forced colours each change behaviour.
• Framework-free, React-friendly. Plain custom elements. React 19 uses them directly — properties, events and all.

Design tokens

Colour, type, spacing, radius, motion and focus tokens are CSS custom properties (--tai-*) generated from one source file. The app switches theme with <html data-theme>; without it, tokens follow the operating system. Each chip shows light (top-left) and dark (bottom-right).

• --tai-color-fg#0E1A2B · #E7EBF3
• --tai-color-fg-muted#475569 · #C3CAD7
• --tai-color-fg-subtle#566174 · #9AA4B6
• --tai-color-canvas#F3F6FB · #0F1218
• --tai-color-surface#FFFFFF · #171B23
• --tai-color-border-control#6F7B8F · #6B768A
• --tai-color-accent#1D4ED8 · #2563EB
• --tai-color-focus#1D4ED8 · #8AB4FF
• --tai-color-up#05694C · #34D399
• --tai-color-down#B42318 · #F87171
• --tai-color-danger#B42318 · #DC2626
• --tai-color-highlight#FDE68A · #4A3B0A

Contrast, measured

“Glass” means the translucent surface composited over each reference backdrop — white, the top and the deepest blue of the homepage hero (light), or the graphite canvas, surface and panel (dark). The ratio shown is the worst case. The unit tests run the same calculation.

When transparency isn't wanted

Under prefers-reduced-transparency or prefers-contrast: more, glass becomes the solid surface colour and the blur is removed. Increased contrast also strengthens borders, darkens caption text and thickens focus rings to 3px.

Using it in an app

// Once, before your UI renders (in Next.js: a small 'use client' module)

import '@tradeaialgo/tai-ui'
import '@tradeaialgo/tai-ui/tokens.css'

React 19 sets known properties as properties and turns ontai-change-style props into event listeners, so there are no wrapper components. Types for JSX are in @tradeaialgo/tai-ui/react.

Server rendering (Next.js)

• The library imports safely on the server — elements are only defined in the browser.
• Elements add their ARIA (role, aria-checked, roving tabindex) when they upgrade, which can happen before React hydrates. That's intended, so mark server-rendered tai-* elements with suppressHydrationWarning.
• Pass arrays and functions (columns, rows) only from client components; they're set as properties in the browser.
• Page-wide resets like Tailwind's preflight can't break the components: box styles live inside the shadow root, not on :host.

Contributing a component

1. Start from a pattern. Find the closest native element first, then the ARIA Authoring Practices pattern. Write the keyboard table before any code.
2. Create the folder src/components/tai-name/ with the element, styles built only from --tai-* tokens, and JSDoc for every attribute, property, event, slot and part.
3. Decide shadow or light DOM — shadow for encapsulated widgets; light when native semantics must stay in the document (tables, form labels).
4. Test three ways: unit tests (Vitest + happy-dom), keyboard tests that follow the APG model (Playwright, real Chrome), and axe-core with zero violations in every documented state.
5. Document it with the same sections as the other pages: live example, API, keyboard, accessibility notes with the decisions you made, do/don't, and a React snippet.

Review checklist

• Every interactive part is reachable and operable by keyboard, with a visible focus ring (3:1).
• Name, role and state are correct in the accessibility tree.
• No information is carried by colour alone.
• Works in light, dark, increased contrast and forced colours; animation stops under reduced motion.
• Events bubble and are composed; nothing is announced more often than a person can follow.
• Docs examples use made-up data.