Accessible UI patterns: WCAG, WAI-ARIA and the APG

Search for "WCAG combobox" or "WCAG tabs" and you land in three different W3C documents that answer different questions. This series explains each common interface pattern of an online shop — what it is for, which WCAG criteria apply, a short correct HTML example, the expected keyboard behaviour and what an automated check can and cannot find. This page explains how the documents fit together and lists all patterns.

This is technical guidance, not legal advice.

WCAG vs WAI-ARIA vs ARIA Authoring Practices

WCAG does not mention a single widget by name. It says, for example, that every control must expose its name, role and state (4.1.2), that everything must work with a keyboard (2.1.1), that focus must be visible (2.4.7) and that structure must be in the code, not only in the layout (1.3.1). Native HTML gives you most of that for free. When you build something HTML does not have — tabs, a combobox with suggestions, a carousel — WAI-ARIA lets you describe it, and the APG tells you how users of assistive technology expect it to behave.

The W3C describes WAI-ARIA as a way to make "dynamic content and advanced user interface controls" accessible, and the APG as a companion that "recommends approaches to help web application developers make widgets" accessible. The APG is not a conformance requirement: you can meet WCAG with a different, well-tested design. Its own introduction says that testing with assistive technology "is essential before using code from this guide in production".

Native HTML first

The W3C note Using ARIA put it as the first rule of ARIA use: if you can use a native HTML element or attribute with the semantics and behaviour you need already built in, use it instead of re-purposing an element and adding ARIA. Its other rules: do not change native semantics unless you really have to; all interactive ARIA controls must be usable with the keyboard; never put role="presentation" or aria-hidden="true" on a focusable element. (That note is now published as a discontinued draft and points to the APG for further guidance, but the rules are still the common baseline.)

The APG says the same in its own words: "No ARIA is better than bad ARIA" and "a role is a promise". Adding role="button" to a div promises a button, but "ARIA roles do not cause browsers to provide keyboard behaviors or styling" — you still have to make it focusable and react to Enter and Space yourself.

<!-- Native: name, role, focus and keyboard for free -->
<button type="button">Add to cart</button>

<!-- Re-built: every piece must be added by hand, and is often forgotten -->
<div role="button" tabindex="0" onclick="add()" onkeydown="addOnEnterOrSpace(event)">Add to cart</div>

The patterns in this series

Basic controls

• Button vs link — buttons do things, links go places
• Links that open in a new tab — when to do it and how to warn
• Disabled buttons — disabled vs aria-disabled, contrast and explanations
• Radio buttons and checkboxes — labels, groups and custom styling

Pop-ups and overlays

• Dropdown, select and combobox — native select first, then the APG combobox
• Modal dialog — focus in, focus trapped, focus back
• Tooltip — WCAG 1.4.13 and why the APG pattern is still a draft

Navigation and structure

• Navigation menu — why the APG recommends disclosure navigation, not menubar, for websites
• Breadcrumbs — a labelled nav and aria-current="page"
• Tabs — tablist, arrow keys and automatic activation
• Accordion — headings with buttons, or details and summary
• Data table — real table markup, headers and captions
• Carousel — pause control, labelled slides, no surprise rotation

Forms

• Form validation and error messages — errors in text, linked to the field, announced

What an automated check finds in patterns

Our checks run axe-core in a real browser against the page as it loads. For patterns that means they reliably find structural problems: buttons and links without a name, form fields without a label, unknown roles, ARIA attributes that are not allowed on a role or point to a missing ID, a tab outside a tablist, focusable elements hidden with aria-hidden. Each finding links to its card in the rule library.

They cannot find behavioural problems: whether arrow keys move between tabs, whether focus enters a dialog and returns afterwards, whether aria-expanded changes when the menu opens, whether a carousel can be paused. Content that is hidden when the page loads, such as a closed dialog, is not tested at all; the browser extension checks the page in the state your browser shows, so you can open the dialog first. Plan the keyboard and screen reader part as described in how to test WCAG.

Start with the free one-page check. It is an automated check, not a full audit.

Frequently asked questions

What is the difference between WCAG and WAI-ARIA?

WCAG says what the result must be, for example that every control exposes its name, role and state (4.1.2). WAI-ARIA is a W3C specification of roles, states and properties that is one way to reach that result when native HTML is not enough.

Does WCAG require ARIA?

No. WCAG is technology-neutral. Native HTML elements such as button, a, input, select and table usually meet the criteria without any ARIA. ARIA is needed for custom widgets that HTML does not provide, such as tabs.

What is the ARIA Authoring Practices Guide (APG)?

A W3C WAI resource that describes how common widgets should behave: which roles and states they use and which keys they support. It is guidance, not a WCAG requirement, and W3C asks to test its examples with assistive technology before using them in production.

What is the first rule of ARIA?

If a native HTML element or attribute already has the semantics and behaviour you need, use it instead of adding ARIA to another element. A real button is better than a div with role button.

Can an automated check test UI patterns?

Partly. It finds missing names, invalid ARIA roles and attributes and broken parent and child roles. It cannot tell whether arrow keys work, whether focus moves correctly or whether states update while you use the widget.

Sources

• W3C WAI, WAI-ARIA overview: https://www.w3.org/WAI/standards-guidelines/aria/
• W3C WAI, ARIA Authoring Practices Guide, Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
• W3C WAI, APG patterns: https://www.w3.org/WAI/ARIA/apg/patterns/
• W3C, Using ARIA (discontinued draft, rules of ARIA use): https://www.w3.org/TR/using-aria/