Learn Accessibility
By Doing

What These Demos Teach

Each pattern page is a short, self-contained lesson on one interface component that is easy to get wrong: a data table, a set of page controls, a modal dialog, a carousel, or a search box with suggestions. The page is split into sections you move between with the tab bar at the top. Most sections pair a working demo with the code that produced it, and several demos have a toggle that swaps between an inaccessible version and the fixed one so you can feel the difference with a keyboard or a screen reader rather than read about it.

The accessible versions follow the W3C ARIA Authoring Practices patterns and the relevant WCAG 2.2 success criteria, and each page ends with a list of the mistakes we see most often in production code. The demos are deliberately minimal. They show the essential markup, focus handling, and announcements, not a production component library, and they are teaching aids rather than proof of conformance for any real product. Test your own implementation against the criteria; do not assume that copying a demo settles the question.

How to Get the Most from a Demo

Put the mouse down. Every accessible demo can be operated with Tab, Shift+Tab, Enter, Space, Escape, and the arrow keys, and each page lists the exact keys it expects. Then turn on a screen reader: on macOS, VoiceOver is built in and starts with Command+F5; on Windows, NVDA is free. Listen for the things sighted users take for granted, such as how many results appeared, which page is current, or that a dialog has opened. If you cannot tell from the audio alone, you have found the gap the lesson is about.

When you are ready to apply a pattern, the keyboard accessibility guide covers the conventions every widget shares, the interactive WCAG checklist tracks which criteria you have verified, and the code generator can draft a starting point in your framework for you to review against what you learned here.