# Accessibility & Keyboard Support

Canonical page: https://www.adaptabletools.com/docs/ui-tutorial-accessibility-keyboard

- AdapTable's UI is built on accessible headless primitives that implement [WAI-ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/)
- Menus, dialogs, comboboxes, tooltips, wizards and other controls expose correct roles, states and focus behaviour by default
- Keyboard interaction follows familiar patterns — arrow keys, Escape, Tab and type-ahead — across the AdapTable UI
- Custom toolbars, panels and cell content you add remain your responsibility to make accessible

AdapTable ships a large UI surface — Dashboard toolbars, Settings Panel wizards, column and context menus, pickers, dialogs and bespoke controls.

These are built on **[Base UI](https://base-ui.com/)** headless primitives, assembled using **[shadcn/ui](https://ui.shadcn.com/)** conventions and styled with **Tailwind CSS** and **CSS variables** (see [Theming AdapTable UI](https://www.adaptabletools.com/docs/handbook-theming/index.md)).

That foundation provides **accessibility and keyboard support out of the box** for AdapTable-owned UI.

See [AdapTable UI Components](https://www.adaptabletools.com/docs/ui-components/index.md) for the full UI stack overview. For background on why AdapTable adopted this stack, see the [Tailwind, shadcn and Base UI in AdapTable](https://www.adaptabletools.com/blog/2026-06-29-using-tailwindcss-shadcn-in-adaptable) blog post.

## Screen Reader & ARIA Support

AdapTable UI primitives implement the WAI-ARIA Authoring Practices for the control types they represent.

In practice this means:

- menus, listboxes, comboboxes, dialogs and popovers are announced correctly to screen readers
- appropriate **`aria-*`** attributes are set — for example `aria-expanded`, `aria-selected`, `aria-controls` and `activedescendant` where relevant
- **focus traps** in modals and popovers work correctly, and focus returns to the trigger when they close
- **`aria-labelledby`** / **`aria-describedby`** relationships are kept consistent across related components

This applies to AdapTable's own Dashboard, wizards, menus, pickers and dialogs — not automatically to arbitrary content you embed in custom toolbars or panels.

## Keyboard Navigation

Keyboard support matches the interaction patterns users expect from modern web applications.

| Key                 | Typical behaviour                                                 |
| ------------------- | ----------------------------------------------------------------- |
| **Arrow keys**      | Move between options in menus, selects and comboboxes             |
| **Home / End**      | Jump to the first or last item in a list                          |
| **Type-ahead**      | Jump to matching items in menus and listboxes                     |
| **Escape**          | Close popovers, dialogs and menus; return focus to the trigger    |
| **Tab / Shift+Tab** | Move focus in a predictable order, including inside modal dialogs |
| **Enter / Space**   | Activate the currently focused item                               |

These patterns apply across AdapTable UI — toolbars, wizards, Settings Panel flows, column menus and similar controls.

AG Grid itself provides keyboard navigation for the grid (cell focus, editing, etc.). AdapTable keyboard support covers **AdapTable UI** around and inside the grid integration — not a replacement for AG Grid's own accessibility documentation.

## Custom UI You Provide

When you extend AdapTable with bespoke UI, accessibility remains partly your responsibility:

- **Custom toolbars, tool panels and popups** — ensure buttons and inputs you add have labels, roles and keyboard handlers as needed (see [Building Custom Components](https://www.adaptabletools.com/docs/ui-tutorial-building-custom-components/index.md))
- **Custom cell renderers and editors** — grid cell content should expose meaningful text or ARIA attributes for assistive technology where appropriate
- **Host application chrome** — page landmarks, skip links and overall document structure live outside AdapTable

AdapTable's built-in controls do not automatically fix accessibility gaps in content you inject.

## Styling & Host-App Tailwind

AdapTable styles its UI with Tailwind utility classes scoped under the **`twa:`** prefix (for example `twa:flex`, `twa:bg-accent`).

This means:

- **No class-name collisions** with Tailwind (or other CSS) in your host application
- **No Tailwind configuration** is required in your project for AdapTable to render correctly
- Theme colours still flow from **CSS variables** — see [Customising AdapTable Themes](https://www.adaptabletools.com/docs/handbook-theming-custom/index.md)

If your app uses Tailwind v4 with cascade layers and prefixed AdapTable utilities appear overridden by your preflight reset, see [Tailwind integration](https://www.adaptabletools.com/docs/technical-reference-theming/index.md#tailwind-integration) in the Theming Technical Reference.

### FAQ

**Does AdapTable support WCAG compliance out of the box?**
AdapTable UI controls are built on accessible primitives and follow WAI-ARIA Authoring Practices. Full WCAG compliance for your application also depends on how you configure the grid, custom UI, colour contrast in your theme overrides, and host-page structure — which only you can validate in context.

**Do I need to configure ARIA for AdapTable menus and dialogs?**
No. AdapTable-owned menus, dialogs, comboboxes and similar controls handle roles, states and focus management internally.

**Will AdapTable's Tailwind clash with mine?**
No. AdapTable uses a `twa:` prefix on all Tailwind utilities and ships a self-contained stylesheet. Your app's Tailwind version and config are independent.