What is the WAI-ARIA Authoring Practices Guide?

The APG is a W3C resource that documents how to build accessible widgets using ARIA roles, states, and properties. It defines a recommended design pattern for each common widget type, including the keyboard model and required attributes. This tool packages the 1.2 patterns for offline reference.

Does activating a button with the Space key also work for links?

No. Native buttons respond to both Enter and Space, but links are activated only by Enter. If you give a custom element role=link, do not bind Space to it, because doing so contradicts the expected link behaviour and confuses screen-reader users.

When should I use aria-activedescendant instead of roving tabindex?

Both are valid focus-management strategies for composite widgets like listbox and grid. Roving tabindex moves real DOM focus between items, while aria-activedescendant keeps focus on the container and points to a virtual active child. Use activedescendant when you must keep focus on an input, such as in a combobox.

Is this data sent anywhere when I search?

No. The entire pattern dataset is bundled into the page as static content and all filtering happens in your browser. There are no network requests, no analytics on your queries, and the tool works fully offline once the page has loaded.

Does following these patterns guarantee WCAG compliance?

Implementing a pattern correctly satisfies many WCAG success criteria related to keyboard operability and name/role/value, but it is not a complete guarantee. You still need sufficient colour contrast, focus indicators, error handling, and content-level conformance, which the APG patterns do not cover.

WAI-ARIA Authoring Practices Pattern Reference

This reference packages the design patterns from the W3C WAI-ARIA Authoring Practices Guide (APG) version 1.2 into a single searchable, offline page. Each pattern lists the role, a one-line summary, the keyboard interaction model, and the ARIA states and properties a correct implementation must expose. Use it as a build-time checklist when you are writing a custom widget that has no native HTML equivalent.

How it works

The tool holds a static dataset of more than twenty-five widget patterns — accordion, alert, alert dialog, breadcrumb, button, checkbox, combobox, dialog, disclosure, feed, grid, link, listbox, menu, radio group, slider, spinbutton, switch, table, tabs, toolbar, tooltip, tree view, tree grid, and window splitter.

When you type into the search box, every pattern is matched against its name, role, summary, and attribute list. Clicking a pattern header toggles its detail panel, which is itself built using the disclosure pattern (a button with aria-expanded) so the tool models the very practices it documents.

For each pattern, two checklists are shown:

Keyboard interaction — the keys a user must be able to press and what each one does. For example, a dialog must trap Tab focus and close on Escape, while a slider responds to arrow keys, Home, End, and Page Up/Page Down.
Required / recommended ARIA — the roles, states, and properties to set. For a tablist that means aria-selected on the active tab, aria-controls linking each tab to its tabpanel, and a roving tabindex.

Notes and tips

A few rules catch developers out repeatedly. Links activate only on Enter, never Space, so do not bind Space to a role=link element. Tooltips must be dismissable with Escape and stay visible while hovered, per WCAG 1.4.13. Modal dialogs must move initial focus inside the dialog and return it to the trigger on close. Accordions only need role=region on their panels when there are six or fewer of them, to avoid landmark clutter.

These patterns are a starting specification, not a conformance certificate. A widget that implements its pattern correctly will still need adequate contrast, visible focus indicators, and accessible labels to meet WCAG in full. When in doubt, test with a real screen reader against the official APG example for the pattern. Everything in this tool runs locally in your browser.