Updated Jul 6, 2026

Accessibility From Day One

A blind developer uses a screen reader to shop online every week. A warehouse worker with a repetitive strain injury navigates his team's internal tools by keyboard because a mouse hurts. Someone with low vision has the browser zoomed to 200%. None of them are edge cases - they're a normal slice of your user base, and most of what they need comes free from writing HTML the way it was designed to be written.

This guide assumes you already know HTML, CSS, and forms from HTML From Zero, CSS Without Tears, and Forms That Work. It builds on that foundation instead of re-explaining it.

The phases

  1. Why Accessibility Isn't Optional - who actually needs this, the four WCAG pillars in plain language, and why semantic HTML already does most of the work.
  2. ARIA, Focus Management, and Keyboard Navigation
    • the first rule of ARIA, tabindex, visible focus styles, and trapping focus in a modal.
  3. Testing with a Screen Reader and Automated Tools
    • turning on VoiceOver or NVDA and tabbing through a real page, plus what Lighthouse and axe can and can't catch.

By the end, you'll know which HTML choices buy accessibility automatically, when ARIA is the right tool versus a crutch for bad markup, and how to verify a page actually works for someone who isn't using a mouse or a monitor the way you are.