// 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.
-
Form Labeling: Deep Dive
A complete guide to form labeling: native
<label>, fieldset and legend, ARIA labeling attributes, hidden labels, placeholder pitfalls, and required/error indicators. -
Headings & Landmarks: Page Structure
Master heading hierarchy and HTML5 landmarks. How screen reader users navigate by structure, the rules that keep your page scannable, and the markup that makes content discoverable.
-
Alt Text & Accessible Images
How to write alt text for informative, decorative, and functional images. Covers SVGs, icons, emojis, complex charts, images of text, and generative AI caveats.
-
Live Regions: Deep Dive
How ARIA live regions announce dynamic changes to screen readers. Covers polite vs assertive, role=alert vs role=status, screen reader quirks, and debugging checklist.
-
Automated Accessibility Testing: Tools, CI/CD, and What to Test
Tools and strategies for automated a11y testing. axe-core, Pa11y, Lighthouse, CI/CD integration, and what automated tests can and can't catch.
-
Focus Management Patterns for Accessible Web Apps
How to manage keyboard focus in web applications. Covers focus trapping, restoration, roving tabindex, programmatic focus, and focus indicators.
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.