Accessible Component Patterns

// what is this

What is an accessible component pattern?

An accessible component pattern is a reusable, tested implementation of a common UI component — a modal, a tab set, a combobox — built so it works for everyone: keyboard-only users, screen reader users, people using voice control or switch devices, and everyone else. A complete pattern specifies the exact roles, states, keyboard interactions, and focus behavior the component needs, and backs them with working code you can copy into your project.

These patterns follow the guidance in the W3C's ARIA Authoring Practices Guide, but go further than the spec: each one shows the native HTML baseline first, explains exactly where ARIA is genuinely required, documents how real screen readers (NVDA, JAWS, VoiceOver) announce the component, and lists the common mistakes that quietly break it. The goal is that you can ship the component without second-guessing.

// the rule

Native HTML first, ARIA only when needed

The single most important principle in accessible component development: don't reach for ARIA when a native HTML element already does the job. A native <button>, <a>, <details>, <dialog>, or <input> ships with built-in roles, states, focus behavior, and keyboard handling that you would otherwise have to rebuild — correctly — with ARIA and JavaScript. The native version is shorter, more robust, and far harder to get wrong.

ARIA earns its place when HTML has no native equivalent — tabs, comboboxes, tree views, and similar rich widgets. For those, the ARIA guide explains how to apply roles and states correctly. Every pattern below is tagged so you can see the tradeoff at a glance:

• native-html  works with little or no ARIA; the native element carries the semantics.
• aria-required  no native equivalent exists, so ARIA is necessary.
• beginner intermediate advanced  how much complexity the pattern involves, so you know where to start.

// choosing a pattern

Which pattern do I need?

All 23 patterns are grouped into three categories below. If you're starting from a task, this map points you to the right one:

Overlays and dialogs

Content that appears on top of the page. Use the modal dialog when the user must respond before continuing, the alert / alertdialog for urgent interruptions, the toast for transient notifications, and the tooltip for supplementary hints on focus or hover.

Expanding and collapsing content

The accordion and disclosure patterns show and hide content with native <details> where possible. For tabbed views, the tabs pattern manages roving focus and panel association.

Navigation

Start every page with skip links. Use the breadcrumb for hierarchy, pagination for paged lists, the responsive nav and mega menu for site headers, and the dropdown menu for action menus.

Forms and inputs

The accessible forms pattern covers labels, grouping, validation, and errors. For specialized inputs, see the combobox, date picker, search field, and switch.

Once you've built a component, verify it against the Developer Accessibility Checklist and test it with the Accessibility Testing Checklist.

// browse by category

Browse by category

All 23 patterns, grouped by category. Each card's code-strip shows the element it's built on; the mono line is its primary WCAG criterion.