Accessibility & ADA Compliance

Semantic HTML, ARIA, keyboard flows, and the legal side of ADA/WCAG — built as a discipline, not a lint-rule afterthought.

0 of 30 lessons complete~366 min total

Start track

Sort

Semantic HTML as the FoundationIntermediateEvery div-based rebuild of a native element is you reimplementing, by hand and usually imperfectly, behavior the browser already gives away for free. Semantic HTML is where accessibility work should start, not where it stops.13 min · 0/3 questions correct
The Accessibility Tree and How Screen Readers Actually WorkIntermediateA screen reader never looks at your CSS. It queries a separate tree the browser builds from the DOM, and understanding that tree is the difference between guessing at accessibility and actually diagnosing it.13 min · 0/3 questions correct
ARIA: When to Use It and the First RuleIntermediateARIA has an actual first rule, and it's not 'add more of it': if a native element already has the semantics you need, use that element instead of rebuilding its meaning by hand.13 min · 0/3 questions correct
Accessible Names, Roles, and DescriptionsIntermediateEvery interactive element needs an accessible name, a role, and sometimes a state — and the most common real-world bug is an icon-only control that quietly has none of the first.12 min · 0/3 questions correct
Forms Accessibility: Labels, Errors, and InstructionsIntermediateA red border and small red text under a field is a purely visual error signal — invisible to a screen reader unless it's also wired up programmatically. Forms are where accessibility bugs compound fastest, and where the fix pattern is fully specified.13 min · 0/3 questions correct
Keyboard Navigation FundamentalsBeginnerA meaningful population of real users never touches a mouse — motor disabilities, screen reader users, power users. If an interactive element can't be reached and operated with a keyboard alone, it doesn't work for them, full stop.12 min · 0/3 questions correct
Focus Management: Trapping and Restoring FocusIntermediateOpening a dialog doesn't just show new content on top of the page — it makes a promise about where keyboard focus goes, stays, and returns to. Most home-rolled implementations keep two-thirds of that promise and quietly drop the last part.13 min · 0/3 questions correct
Roving Tabindex and Composite WidgetsIntermediateA toolbar of 10 buttons shouldn't cost a keyboard user 10 Tab presses just to get past it. Roving tabindex is the pattern that makes a whole group of controls behave as one stop in the page's tab order.13 min · 0/3 questions correct
Skip Links and Bypass BlocksBeginnerA mouse user reaches the main content of any page in one click, no matter how big the navigation is. Without a bypass mechanism, a keyboard user has to Tab through every single nav link first, on every single page.10 min · 0/3 questions correct
Building an Accessible Modal DialogIntermediateAn accessible modal isn't one property to set — it's a checklist of five distinct requirements, and the most common production bug is getting the visual overlay right while quietly shipping only two or three of the five.14 min · 0/3 questions correct
Accessible Dropdowns and ComboboxesIntermediateA native <select> gets keyboard behavior, screen reader announcement, and mobile picker integration for free. The moment you build a custom autocomplete instead, all of that becomes your job.14 min · 0/3 questions correct
Accessible Tabs and AccordionsIntermediateTabs and accordions are both progressive disclosure — show one thing, hide the rest, expose which is which — but they use different ARIA shapes and a div-with-onClick version of either is invisible to a screen reader.12 min · 0/3 questions correct