// native html first, ARIA only when needed
Accessible components, done right.
Production-ready patterns with live demos, copy-paste code, and the reasoning behind every decision — built on the elements the browser already ships.
Component Patterns
Each includes a working demo, complete source, keyboard guide, screen reader notes, and WCAG 2.2 success-criteria mapping.
-
Button
Native
<button>with propertype. Covers icon-only buttons, toggle buttons witharia-pressed, loading states, and disabled vsaria-disabled. -
Card
Clickable card with a single anchor and
::afterexpansion. Avoids nested-link traps and<div onclick>anti-patterns. Multi-action card variant included. -
Search Field
Search form with
role="search"landmark, accessible label, clear button, results count live region, and recent searches list. -
Alert / Banner
Persistent inline messages with the right ARIA live region role. Distinguishes
role="alert"(urgent) fromrole="status"(polite). -
Disclosure
Single show/hide widget using native
<details>/<summary>. The flagship native-first pattern — zero JavaScript, zero ARIA. -
Pagination
Page navigation with a
<nav>landmark, real links, andaria-current="page". Works without JavaScript and survives refresh. -
Carousel / Slider
Auto-rotating content carousel with pause control, dot indicators,
aria-roledescription, keyboard navigation, andaria-liveannouncements. -
Date Picker
Calendar date picker with
role="grid", keyboard grid navigation, text input fallback, and screen reader announcements. -
Mega Menu
Multi-column dropdown navigation with grouped links,
aria-expandedtriggers, keyboard navigation, and focus management.
// the premiseWhy native HTML first?
Most accessibility failures come from reinventing what the browser already provides. A <button> gives you keyboard interaction, focus management, and screen reader semantics for free.
A <div onclick> gives you none of that — and needs ARIA, tabindex, and keyboard handlers just to catch up.
Every pattern here starts with native elements and only layers ARIA when semantics fall short. Modals, accordions and breadcrumbs use zero or minimal ARIA.
Others — tabs, comboboxes, dropdown menus — show exactly why ARIA exists: no native equivalent, so roles are the only way to convey structure to assistive tech.
Each pattern explains why each decision was made, and where the line sits between helpful ARIA and needless complexity.
Guides
Read these to understand the why behind the patterns.
-
The Best Automated Accessibility Testing Tools, Compared
A practical comparison of automated accessibility testing tools — axe-core, Pa11y, Lighthouse, WAVE, IBM Equal Access, and test-framework integrations. What each does, how they overlap, and the stack to standardize on.
-
Accessible Authentication: WCAG 3.3.8 and Passwordless Login
WCAG 3.3.8 accessible authentication: cognitive function tests, supporting password managers and paste, autocomplete attributes, passkeys and magic links, and CAPTCHA accessibility.
-
Accessible Links: Text, Purpose, and Common Mistakes
Writing link text that makes sense out of context (WCAG 2.4.4), links versus buttons, warning about new tabs and downloads, naming icon-only links, and making links look like links.
-
Accessible Media: Captions, Transcripts, and Audio Description
Who needs captions, transcripts, and audio description, what the WCAG 1.2 media criteria require, captions vs subtitles, and adding captions with the HTML track element and WebVTT.
-
Accessible Forms in React: Labels, Errors, and useId
Accessible React forms: label association with useId, controlled inputs, announcing validation errors with aria-live and aria-describedby, grouping controls, and submission feedback.
-
Accessible Motion and Animation: prefers-reduced-motion and WCAG
Who motion affects, what WCAG requires (pause/stop/hide, no flashing, animation from interactions), and honoring prefers-reduced-motion in CSS and JavaScript.
Checklists
Check off items as you go — progress is saved automatically. Print-friendly for code review and QA.
-
React Accessibility Checklist
React-specific accessibility issues most teams miss: route-change focus, ARIA state syncing, useId, Portals + dialogs, controlled-component forms, and React Testing Library queries. 36 items.
-
Pre-launch Accessibility Checklist
The final accessibility check before shipping. 30 items across 7 groups covering keyboard, screen readers, forms, color, errors, and pre-launch edge cases.
-
Content & Editorial Accessibility Checklist
For writers, editors, and content designers. 25 items covering plain language, headings, link text, alt text, inclusive language, and UX writing.
-
SPA Accessibility Checklist
24-item checklist for single page application accessibility covering route changes, focus management, dynamic content, error handling, and testing.
-
WCAG 2.2 Compliance Checklist
Every WCAG 2.2 Level A and AA success criterion mapped to an actionable check. 54 items organized by the four principles.
-
Forms Accessibility Checklist
24-item checklist covering labels, grouping, validation, error handling, input types, and keyboard interaction for accessible forms.