Design Pattern

A design pattern is a documented model that describes how to build an accessible rich interface component. It specifies the ARIA roles to use, the states to manage, and the keyboard interactions to code. The W3C publishes about thirty in the APG (Authoring Practices Guide), covering tabs, modals, application menus, and accordions.

You're building a tabs system in JavaScript. The visual rendering is correct, the panels display on click. But a screen reader user perceives only a series of meaningless <div> elements. The missing piece is the instructions: the design pattern.

#What a design pattern contains

An ARIA design pattern is a technical sheet published in the W3C APG. Each sheet describes three things:

  1. The ARIA roles to assign to elements (tablist, tab, tabpanel for tabs).
  2. The states and properties to maintain (aria-selected, aria-controls, aria-expanded).
  3. The expected keyboard behavior (arrow keys to navigate between tabs, Enter to activate).

Here is a tabs system that follows the APG Tabs pattern:

<div role="tablist">
  <button role="tab" aria-selected="true"
          aria-controls="panel-1" id="tab-1">Tab 1</button>
  <button role="tab" aria-selected="false"
          aria-controls="panel-2" id="tab-2" tabindex="-1">Tab 2</button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  Content of the first tab.
</div>

Without these attributes, a screen reader sees buttons and text blocks. With them, it announces "tab 1 of 2, selected" and the user knows exactly where they are.

#The menu pattern trap

The RGAA developer guide lists approximately 39 ARIA patterns. The most misused: menu. Many developers apply role="menu" and role="menuitem" to their navigation bar. This is a mistake.

The ARIA menu pattern reproduces the behavior of a desktop application menu (like File, Edit, View). Navigation between items uses arrow keys, not tab. When you apply it to a web navigation menu, you break the expected keyboard flow. Access42 documented this issue: for site navigation, a simple <nav> with a list of links is sufficient.

#Following a pattern does not guarantee WCAG conformance

Common misconception: "if I follow the APG pattern, my component is WCAG compliant." TetraLogical clarified this in 2024: design patterns are a recommendation, not a conformance criterion. Your component must comply with WCAG criteria (operable by keyboard, properly named, compatible with assistive technologies), whether you follow an APG pattern or not. The RGAA glossary says "it is recommended," not "it is mandatory."

Patterns remain the best available reference. But they do not replace keyboard and screen reader testing.

#In summary

A design pattern is the assembly guide for an accessible component: roles, states, keyboard. Consult the W3C APG before coding a rich component. Be wary of the menu pattern for navigation. And always test the result with a screen reader.

Back to glossary
Share this article

Learn more

UI Component

A UI component is a page element with which the user interacts: button, link, input field, menu, or tab system. When it's a native HTML element, the browser handles accessibility. When built in JavaScript, it's the developer's responsibility to reproduce that behavior with WAI-ARIA and keyboard management.

ARIA

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that describe interface components to assistive technologies. A custom button, a tabbed system, a dynamic notification: when semantic HTML is not enough, ARIA adds the missing information. But an ARIA attribute without the corresponding behavior does more harm than good.

Keyboard Accessible and Activatable

A component is « keyboard accessible » when you can select it with Tab, and « activatable » when you can trigger its action with Enter or Space. Native HTML elements like <a>, <button> and <input> are by default. A <div> with an onclick, is not.