WAI-ARIA Authoring Practices: The Cookbook for Accessible Components
Think of WAI-ARIA Authoring Practices as the official cookbook for accessible web components. It provides patterns for widgets like tabs or accordions, ensuring they work with assistive tech.
Why it exists
The ARIA specification defines attributes like role or aria-checked, but it doesn't explain how to combine them with HTML and JavaScript to build a fully functional, accessible component. The WAI-ARIA Authoring Practices Guide (APG) was created to fill this gap, providing a practical guide for developers on how to implement common widgets correctly.
The mental model
The APG is a collection of design patterns and recipes for building common web widgets accessibly. For any given component, like a modal dialog or a set of tabs, it tells you what HTML structure to use, which ARIA roles and properties to apply, how their states should change, and exactly how it must behave with keyboard input. It's the bridge between the abstract ARIA spec and a working, compliant component.
How it works
The guide is organized by pattern. For each pattern, such as "Tabs" or "Accordion," it provides: first, a description of the expected user experience; second, detailed keyboard interaction requirements (e.g., Left/Right arrows navigate tabs); third, the necessary WAI-ARIA roles, states, and properties (e.g., role="tablist", aria-selected); and fourth, functional code examples demonstrating a correct implementation.
When to use it
Use the APG as your primary reference whenever you are building a custom interactive component that isn't a standard HTML element. This includes custom dropdowns, carousels, sliders, tooltips, and complex data grids. It is an essential resource for design system teams creating a library of reusable, accessible components.
When not to use it
Avoid ARIA and the APG when a native HTML element already provides the required semantics and behavior. For example, use a native <button> element instead of building a button from a with role="button". The first rule of ARIA is "don't use ARIA" if a native element will do. The APG is for rich internet applications where native elements fall short.
One canonical example
Consider building a tabbed interface. The APG specifies that the container needs role="tablist". Each tab control needs role="tab", and its associated panel needs role="tabpanel". Crucially, the APG dictates that only one tab can have aria-selected="true" at a time, and that arrow keys should move focus between tabs, while the Tab key moves focus out of the component. Without the APG, a developer might guess at the roles and miss the required keyboard interaction model.
Interview question
The WAI-ARIA Authoring Practices Guide (APG) bridges a crucial gap between the abstract ARIA specification and practical implementation. What specific type of guidance does it primarily offer to achieve this?
- a.Prescriptive patterns for HTML structure, ARIA usage, and essential keyboard behaviors for common interactive components.Correct
- b.Techniques for automatically detecting and fixing accessibility errors in existing web applications.
- c.A comprehensive catalog of all ARIA attributes and their allowed values.
- d.Best practices for optimizing ARIA attributes for performance in large-scale applications.
Why? this is the answer
The APG's primary role is to provide practical, prescriptive guidance on how to combine HTML, ARIA, and JavaScript to build fully functional, accessible components, including detailed keyboard interaction models. The ARIA specification itself defines the attributes, but not their practical implementation patterns.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
- #accessibility
- #aria
- #design patterns
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles