Accessibility is not a feature you bolt on before launch. It is a structural decision that shapes every component in your design system from day one.
At Agentkit, we ship a dashboard that surfaces complex agent traces, execution logs, and real-time metrics. Our users include engineers who navigate entirely by keyboard, teams who rely on screen readers to review agent output, and operators who need high-contrast modes to monitor production systems in bright server rooms.
The cost of retrofitting
Most teams treat accessibility as a QA checklist. The component is built, styled, shipped — and then someone files a ticket about keyboard navigation. By that point, the fix is a patch, not a pattern.
We learned this the hard way with our first trace timeline component. It was a beautiful nested tree of expandable steps, tool calls, and model responses. It was also completely unusable without a mouse.
Rebuilding it took three sprints. Building it right from the start would have taken one.
Our framework
Every component in the Agentkit design system now passes through four gates before it ships:
Gate 1 — Semantic structure. Does the component use the correct HTML elements? A clickable row is a button, not a div with an onClick. A navigation list is a nav with an unordered list, not a stack of styled spans.
Gate 2 — Keyboard interaction. Can every action be performed without a mouse? We map every interactive element to a keyboard pattern from the WAI-ARIA Authoring Practices. Accordions use arrow keys. Modals trap focus. Tabs respond to arrow and home and end keys.
Gate 3 — Screen reader announcement. Does the component communicate its state? We test every component with VoiceOver and NVDA before merge. Expandable sections announce whether they are expanded or collapsed. Loading states announce when content arrives.
Gate 4 — Visual resilience. Does the component work at 200% zoom, in forced-colors mode, and at WCAG AAA contrast ratios? We use CSS custom properties for every color token so that high-contrast themes are a single variable swap.
Practical examples
Our FAQ accordion component — the one you see on our pricing page — is a good example. Each item is a button with aria-expanded. The answer region has role region and aria-labelledby pointing back to the question. The plus icon rotates to a close icon visually but the accessible label simply reads expanded or collapsed.
Our trace timeline uses a tree pattern. Each node is a treeitem with aria-level, aria-setsize, and aria-posinset. Expanding a node moves focus to the first child. Collapsing moves focus back to the parent.
The takeaway
Accessibility is not about compliance. It is about building components that work for everyone by default. If your foundational components are accessible, everything built on top of them inherits that quality automatically.
Start at the foundation. The rest follows.