Accessible Components, Done Right
Production-ready patterns with live demos, copy-paste code, and the reasoning behind every accessibility decision. Native HTML first, ARIA only when needed.
Component Patterns
23 patterns and growing. Each includes a working demo, complete source code, keyboard interaction guide, screen reader behavior 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.
Why 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 requires ARIA attributes, tabindex, and keyboard event handlers to catch up.
Every pattern on A11yPath starts with native HTML elements and only layers ARIA when native semantics fall short. Patterns like modals, accordions, and breadcrumbs use zero or minimal ARIA. Others — tabs, comboboxes, and dropdown menus — demonstrate exactly why ARIA exists: there are no native HTML equivalents, so ARIA roles are the only way to communicate their structure to assistive technology.
Each pattern doesn't just show you the code. It explains why each decision was made, what you get for free from native elements, and where the line is between helpful ARIA and unnecessary complexity.
Guides
Conceptual deep dives on accessibility topics. 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
Interactive checklists with progress tracking. Check off items as you go — your 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.