Accessibility for Developers
Accessibility is not a nice-to-have — it is a legal requirement in most jurisdictions and a quality signal that impacts every user. This course teaches practical, code-level accessibility: semantic HTML, ARIA, keyboard navigation, colour contrast, accessible forms, and building a real CI gate that catches regressions automatically.
What you'll learn
Course outline
Free — no account needed
Why Accessibility Matters — and What WCAG Actually Is
Disability categories, WCAG 2.2 principles, legal requirements, the business case, and assistive tech overview
Semantic HTML — The Foundation of Accessible Interfaces
Landmark elements, heading hierarchy, button vs div, label elements, list semantics, table headers
ARIA — When HTML Isn't Enough
ARIA roles, states, and properties; aria-label vs aria-labelledby; live regions; authoring practices; when NOT to use ARIA
Full course — $39 one-time
Keyboard Navigation and Focus Management
tabindex, focus visible, skip links, focus trapping in modals, managing focus after dynamic changes, roving tabindex
Colour, Contrast, and Visual Accessibility
Contrast ratios (AA vs AAA), tools for checking, colour-blind-safe palettes, text spacing requirements, focus indicator design
Forms and Error Handling
Accessible form patterns, fieldset and legend, error announcement with ARIA, required field patterns, autocomplete attributes
Testing for Accessibility
axe-core and jest-axe, screen reader testing, keyboard-only testing checklist, Lighthouse audit, building an a11y CI gate
Get the full course
7 lessons — practical, project-based, no fluff.
About this course
Web accessibility means building websites that people with disabilities can use — people who rely on screen readers, keyboard navigation, high-contrast modes, or reduced-motion settings. It is not an optional polish pass. In many jurisdictions, accessibility is a legal requirement. More practically, the patterns that make a site accessible also make it faster, more semantic, and easier to maintain. This course teaches the practical skills that let you write accessible code from day one rather than retrofitting it later.
Most accessibility problems are caused by a small set of common mistakes: missing form labels, wrong heading hierarchy, non-descriptive link text, keyboard traps, and insufficient colour contrast. This course walks through each category with real code examples, screen reader demonstrations, and automated testing tools. By the end, you will be able to audit any page and fix the issues that affect the largest number of users.
Frequently asked questions
What is WCAG and do I need to comply with it?
WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility, published by the W3C. WCAG 2.1 AA is the level required by most accessibility laws worldwide — the EU Web Accessibility Directive, the UK Equality Act, the US Section 508 standard, and the ADA (as interpreted in US case law) all reference it or an equivalent level. If you are building a public-facing web product, WCAG 2.1 AA compliance is the practical target.
How do I test my site for accessibility?
Use a combination of: automated tools (axe-core, Lighthouse accessibility audit, Deque axe DevTools Chrome extension — they catch 30–40% of issues automatically), keyboard testing (tab through every interactive element without a mouse — can you complete every task?), and screen reader testing (NVDA on Windows, VoiceOver on Mac — listen to how your content is announced). Automated tools miss most issues; manual testing is essential.
What are ARIA roles and when should I use them?
ARIA (Accessible Rich Internet Applications) roles and attributes communicate semantic meaning to assistive technology when native HTML elements do not express it. The rule: use native HTML elements first — a <button> is better than a <div role="button">. Use ARIA when you are building a custom widget (a carousel, a date picker, a disclosure widget) that has no native HTML equivalent. Misused ARIA is worse than no ARIA — it can make pages less accessible by contradicting what the browser already communicates.
What colour contrast ratio do I need?
WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt+ or 14pt bold+). WCAG AAA requires 7:1 for normal text. Use the WebAIM Contrast Checker or browser devtools to verify. Common failures: grey text on white backgrounds, light blue links on white, and placeholder text in forms (which is always too light by default). If in doubt, make it darker.
Does using a component library like shadcn/ui or Radix make my app automatically accessible?
Radix UI primitives are built with accessibility as a core requirement — keyboard navigation, focus management, ARIA attributes, and screen reader announcements are handled for you. shadcn/ui is built on Radix. Using these libraries removes the hardest part of accessible component development. You still need to: write accessible HTML around them, ensure colour contrast meets standards, write descriptive labels and alternative text for images, and maintain heading hierarchy.