Some of the people using your app can't see the screen, can't use a mouse, or rely on assistive technology to read the page. Accessibility is a spectrum of support, and nobody expects a junior developer to master all of it. We do expect the basics: markup that says what things are, focus that behaves, and a keyboard that works everywhere. This card teaches those basics and lets you experience your own MovieDB the way a screen-reader user does.
Important
Work on this lesson in
teachermode.
Learning goals
- You can explain that accessibility support comes in levels, and which basics we expect in every app we build.
- You can structure a page with semantic elements and headings so that landmarks and outline are meaningful to assistive technology.
- You can keep focus under control and make every interaction reachable and usable with the keyboard alone.
- You can explain when semantic HTML is not enough and ARIA attributes are needed, and use them correctly.
- You can explain why built-in HTML elements are preferable to custom JavaScript components: they bring keyboard activation, focus handling and semantics for free, so extend them instead of rebuilding them.
- You can use accessible markup to make tests more robust, e.g. by matching elements by their accessible name or
aria-label.
Resources
Read what's new to you, skim what's familiar, skip what you already master. Stop when you can meet the learning goals.
Your agent can also generate an overview, a tutorial or an explanation for anything here, tailored to what you already know. Just ask.
Pick one introduction
- 📄 MDN: Accessibility Show archive.org snapshot — the beginner module; the lessons HTML: A good basis for accessibility Show archive.org snapshot , CSS and JavaScript accessibility best practices Show archive.org snapshot and WAI-ARIA basics Show archive.org snapshot cover this card
- 📄 web.dev: Learn Accessibility Show archive.org snapshot — Google's course; same ground, more interactive
- ▶️ Introduction to Web Accessibility and W3C Standards Show archive.org snapshot — W3C WAI, short overview of what accessibility means and for whom
For specific goals
- 📄 WebAIM: Introduction to Web Accessibility Show archive.org snapshot — the levels of support and who is affected
- 📄 ARIA Authoring Practices Guide: Read Me First Show archive.org snapshot — "No ARIA is better than bad ARIA": why built-in elements beat custom components, and when ARIA is needed; the patterns Show archive.org snapshot show what a keyboard-operable widget has to do
- 📄 Inclusive Components Show archive.org snapshot — how to build common components (menus, toggles, tabs) accessibly, extending built-ins where possible
- 📄 Unpoly: Focus Show archive.org snapshot — how Unpoly manages focus when fragments change, and how to control it
- 📄 The A11Y Project checklist Show archive.org snapshot — a checklist for the basics we expect in every app
- 📄 capybara_accessible_selectors Show archive.org snapshot — finding elements by role and accessible name in feature specs; also shows why accessible markup makes tests more robust
- 📄 Orca screen reader documentation Show archive.org snapshot — for the exercise on Linux
Exercises
Use MovieDB with your eyes closed
Install a screen reader (on Linux probably Orca) and learn the few commands you need to navigate a page.
Then use your own MovieDB with the screen reader and your eyes closed: browse the movie list, open a movie, create one, edit it, delete it. Note every point where you get lost, where focus jumps somewhere unexpected, where a control has no name, or where the keyboard doesn't get you further.
Fix the issues you found. Then repeat the tour.
