The ARIA Authoring Practices Guide is W3C's pattern library for interface widgets, and the index runs to thirty. Tabs, tree views, comboboxes, dialogs, carousels. Some are things HTML has no element for. Others are things it does, because people rebuild those by hand anyway. Each one gives the markup, the roles, the states and, above all, the keyboard behaviour people expect, because browsers supply none of that for a control you built yourself. It is where W3C now sends readers for this, since Using ARIA, the document that used to carry the rules of ARIA use, has been discontinued and points here instead. Two limits are worth carrying in with you. The sample code is written to demonstrate the specification rather than to survive contact with real assistive technology, so W3C tells you to test anything you copy. And thirty is fewer than it sounds, because the pattern you came looking for is often not one of them.
In practice
Open the pattern rather than reading the guide. Each page gives the markup, the roles, the states and the keyboard contract for one widget. The keyboard contract is the half that matters, because ARIA announces what a thing is and browsers add no behaviour to match. W3C's own phrasing is that a role is a promise. Give a div the button role and you have told everybody it behaves like a button. Now you owe them the keyboard behaviour a button has, which the browser will not supply on your behalf.
Half the guide is not patterns at all. Seven cross-cutting practice pages sit alongside them. Landmark regions, accessible names and descriptions, building a keyboard interface, grid and table properties, values and limits on range widgets, structural roles, and hiding semantics with the presentation role. Several patterns also cover things HTML already gives you, such as buttons, links, checkboxes and tables, and those exist to spell out what you took on by rebuilding them.
The gaps catch people out, because the ones people go looking for are often not there. Pagination, drag and drop and site search have no pattern at all. A date picker turns up only as a worked example under the modal dialog pattern, and a toast belongs to the alert pattern rather than one of its own. The code is also pinned to ARIA 1.2 and to current Chrome, Firefox and Safari, which is one more reason to test rather than to paste.
Why it matters
Most custom widget failures are not wrong ARIA. They are missing keyboard behaviour, which is the thing ARIA never supplies and the thing this guide exists to specify. The warning attached to it matters as much, because W3C says outright that the sample code deliberately does not work around gaps in browser and assistive technology support. Copying a pattern is the start of the work. Testing it against the software your audience actually runs is the rest of it.
What the guide will not do for you
The examples are written to illustrate the specification, not to ship. W3C tells you to test each one thoroughly with every browser and assistive technology combination that matters to your audience, because the code intentionally leaves known support gaps unpatched rather than working around them.
Where this shows up on the site
Related terms
- ARIAARIA is a set of attributes that tell assistive technology what a custom control is and what state it is in.
- RoleA role is what kind of thing an element is, as reported to assistive technology.
- Keyboard accessibilityKeyboard accessibility means every piece of functionality on the page can be operated through a keyboard interface.
- WAIWAI is the branch of the W3C that develops accessibility standards and guidance.
- Name, Role, ValueName, role and value are the facts assistive technology needs about a control, and the shorthand quietly drops one.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.