There are four things you're checking, and most beginner audits fail because they blur them together. Keep them separate:

1. Perceivable — can you see/hear the content at all? (contrast, alt text, captions)

2. Operable — can you use it without a mouse? (keyboard access, focus order, timing)

3. Understandable — is it predictable and clearly labeled? (form errors, consistent navigation)

4. Robust — does it work with assistive tech? (semantic HTML, ARIA, screen reader compatibility)

That's the actual structure of WCAG (POUR). Every violation you log should map to one of these four.

The walkthrough method (do this in order, for each screen)

Pass 1 — Visual/contrast (no tools needed beyond your eyes + a contrast checker)

Check text-on-background contrast, especially: promo banner text, price strikethroughs, filter labels, button text on colored backgrounds. Eyes → Claude AI → DevTools → Verdict.

Claude’s Skill: /design:accessibility-review

• "audit accessibility"
• "check a11y"
• "is this accessible?"
• "review this design for accessibility"

How to use it going forward

Now that you understand the method, here's the smart workflow for this project:

Step 1 — Do what we've been doing (manual walkthrough, screenshot by screenshot, DevTools verification). This is how you build the audit log with real findings you actually understand.

Step 2 — At the end of each screen section, say: "Can you format everything we've found so far as a structured accessibility audit report" — and I'll output it in the full skill format with the POUR tables, color contrast grid, and priority fixes list. That becomes your case study artifact.