Skip to main content

Building Accessible AI for Business

· 7 min read
Marvin Danig
CEO & Principal Researcher
Casey Brooks
Executive Assistant to CEO

January 25, 2026. Accessibility isn't a feature—it's a fundamental right. Today, we're sharing how we built Achiral AI's chat interface with accessibility at its core, ensuring that every user, regardless of ability or input method, can fully engage with AI assistance.

What is Achiral AI?

Achiral AI is a privacy-first AI platform for businesses with enterprise-grade, self-hosted, secure infrastructure. Our multi-tenant architecture provides organizations with dedicated AI assistants (Chiro) while maintaining complete data isolation and HIPAA/SOC 2 compliance.

The Challenge: Making AI Universally Accessible

As AI becomes increasingly integrated into enterprise workflows, we face a critical question: Is this technology truly accessible to everyone? Too often, modern web applications—particularly those featuring real-time chat interfaces—create barriers for users who rely on assistive technologies or prefer keyboard navigation.

At Achiral AI, we believe that enterprise AI should be inclusive by design. Our unified chat interface needed to serve not just users with diverse abilities, but also power users who navigate primarily by keyboard, IT professionals managing systems without mice, and anyone who values efficient, standards-compliant web experiences.

Our Approach: WCAG 2.1 Level AA Compliance

We committed to meeting Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards—not as a checkbox exercise, but as a design philosophy. This meant fundamentally rethinking how users interact with our interface.

1. Semantic HTML and ARIA Labels

Every interactive element in our chat interface carries semantic meaning. We implemented comprehensive ARIA (Accessible Rich Internet Applications) labels across all components:

Message Display

  • Each message is marked with role="article" for semantic structure
  • Dynamic aria-label attributes describe the sender, timestamp, and message state
  • aria-describedby links messages to metadata like edit timestamps or deletion status
  • Live regions with aria-live="polite" announce typing indicators without interrupting the user's flow

Navigation Structure

  • Conversation lists use proper <nav> elements with role="navigation"
  • Semantic list structures (<ul>, <li>) with role="list" and role="listitem"
  • aria-current="page" indicates the active conversation
  • Unread message counts are announced contextually

Interactive Elements

  • Input fields use role="combobox" for mention dropdowns with proper aria-expanded and aria-controls relationships
  • Context menus implement role="menu" and role="menuitem" patterns
  • Action buttons carry descriptive aria-label attributes like "Copy message text" rather than generic "Copy"

2. Complete Keyboard Navigation

We designed our interface to be fully operable without a mouse. Every function accessible via mouse has an equivalent keyboard shortcut or navigation pattern:

Message Navigation

  • Arrow keys (↑/↓) navigate through messages
  • Home/End jump to first/latest messages
  • Tab cycles through interactive elements
  • Visual focus indicators with high-contrast rings

Conversation Management

  • Arrow keys or Vim-style j/k navigate conversations
  • Enter opens the selected conversation
  • Delete key (with confirmation) removes conversations
  • Escape always returns to the previous context

Context Menus and Modals

  • Tab/Shift+Tab cycle through menu items
  • Arrow keys provide alternative navigation
  • Enter/Space activate selections
  • Escape closes without action
  • Focus automatically moves to the first item on open
  • Focus traps prevent keyboard users from losing context

Global Shortcuts We implemented cross-platform keyboard shortcuts that work with both Cmd (macOS) and Ctrl (Windows/Linux):

  • Cmd+K / Ctrl+K: Focus search
  • Cmd+N / Ctrl+N: Start new conversation
  • Cmd+Enter / Ctrl+Enter: Send message
  • Cmd+/ / Ctrl+/ / ?: Show keyboard shortcuts help
  • @: Trigger assistant mentions in group chats

3. Focus Management

Proper focus management is critical for keyboard and screen reader users. We implemented three key patterns:

Focus Trap Modals and menus trap focus within their boundaries, preventing users from accidentally navigating behind them. When a dialog opens, focus moves to the first interactive element, and Tab/Shift+Tab cycle only through elements within that context.

Focus Restore When closing a modal or menu, focus automatically returns to the trigger element. This preserves the user's place in the interface and prevents disorientation.

Skip Links We provide invisible "Skip to main content" links that become visible on keyboard focus, allowing users to bypass navigation and jump directly to the primary content area.

4. Screen Reader Optimization

Our interface is tested with VoiceOver (macOS), NVDA (Windows), and JAWS to ensure announcements are clear and contextual:

  • Typing indicators announce: "Assistant is typing"
  • Message actions announce their full context: "Delete this message"
  • Conversation state changes announce: "Conversation archived"
  • Toast notifications use role="alert" for immediate announcements
  • ARIA live regions provide non-intrusive updates

5. Visual Accessibility

Beyond assistive technologies, we designed for users with different visual needs:

High Contrast Mode Our interface automatically adapts when users enable high contrast mode:

@media (prefers-contrast: high) {
*:focus {
outline: 3px solid !important;
outline-offset: 2px !important;
}
}

Reduced Motion For users sensitive to motion or with vestibular disorders, we respect the prefers-reduced-motion media query:

@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}

Essential state changes still occur instantly—we simply eliminate decorative animations.

Color Contrast All text meets WCAG AA standards with minimum 4.5:1 contrast ratios for normal text and 3:1 for large text and UI components.

6. Progressive Enhancement with Loading States

Accessibility extends to perceived performance. We implemented skeleton loaders that:

  • Match the exact dimensions of real components
  • Use subtle animations (respecting prefers-reduced-motion)
  • Provide clear loading context to screen readers
  • Smoothly transition to actual content

The Technical Implementation

Our accessibility infrastructure is built on reusable patterns:

Custom Hooks

  • useKeyboardShortcuts: Manages global keyboard shortcuts with platform detection
  • useFocusTrap: Implements focus containment for modals and menus
  • useFocusRestore: Restores focus to previous elements on close
  • useReducedMotion: Detects user motion preferences
  • useAriaAnnouncer: Creates live regions for dynamic announcements

Composable Components Every component follows accessibility patterns from the start. For example, our KeyboardShortcutsModal combines focus trap, focus restore, and ARIA labels in a single, reusable implementation.

Impact and Lessons Learned

Building accessibility-first taught us three critical lessons:

1. Accessibility Improves UX for Everyone Keyboard shortcuts that help screen reader users also delight power users. Clear, semantic HTML improves SEO and code maintainability. Focus management prevents modal confusion for all users.

2. Accessibility Cannot Be Retrofitted Attempting to add ARIA labels to an existing interface is exponentially harder than designing with them from the start. Accessibility decisions influence architecture, state management, and component design.

3. Testing Is Non-Negotiable Automated accessibility checkers catch only 30-40% of issues. Real testing with screen readers, keyboard-only navigation, and users with diverse abilities is essential.

Looking Forward

This is not the end of our accessibility journey—it's the foundation. We're committed to:

  • Regular audits with assistive technology users
  • Continuous testing with VoiceOver, NVDA, and JAWS
  • Expanding support for additional input methods
  • Open-sourcing our accessibility patterns

Resources

We've documented our accessibility implementation comprehensively:

  • Integration Guide: /src/docs/keyboard-shortcuts-integration.md
  • Accessibility Guide: /src/docs/accessibility-guide.md
  • Testing Checklists: Screen reader, keyboard navigation, and color contrast procedures

Try It Yourself

Experience our accessible interface at achiral.ai. Navigate entirely by keyboard. Enable VoiceOver or NVDA. The interface adapts.

Because at Achiral AI, we believe AI assistance should be available to everyone—regardless of how they interact with technology.

Ready to Get Started?

Achiral AI provides WCAG 2.1 Level AA compliant interfaces across all tiers, from solo entrepreneurs to global enterprises.


Building accessible software requires intentionality, testing, and humility. We're grateful to the accessibility community for their advocacy and expertise. If you discover accessibility barriers in our interface, please let us know—we're committed to continuous improvement.

Technical Notes

Stack: React 18, Next.js 14, Tailwind CSS
Compliance: WCAG 2.1 Level AA
Tested With: VoiceOver, NVDA, JAWS, Chrome DevTools Accessibility Panel
Browser Support: Chrome 120+, Firefox 121+, Safari 17+, Edge 120+


Sonica Arora leads engineering at Achiral, where she architects systems that balance performance, security, and accessibility.

Harpreet Singh designs user experiences at Achiral, ensuring that every interaction is intuitive, efficient, and inclusive.

Stay informed on AI infrastructure

Get insights on private AI deployment, compliance, and best practices delivered to your inbox.

Start free trial