We closed Module 5 with an uncomfortable question: we now know how to build accessible components—an accordion with aria-expanded, a modal with a focus trap, a video with <track>—but do they really work? An aria-expanded that doesn't stay in sync, a leaky focus trap, or an alt that sounds odd in NVDA aren't caught by the code: they're caught by someone testing. This module is the verification phase, and it starts with the cheapest and most revealing approach of all: testing by hand, yourself, with no expensive licenses. In this lesson you'll learn to audit the Cursalia course page using nothing but your keyboard, a free screen reader, browser zoom, and DevTools.

1. Why start with manual testing
2. Keyboard-only testing
3. Screen reader testing for developers
4. Zoom and reflow testing
5. Structure verification with DevTools
6. Manual contrast checking
7. The "first criterion the rush breaks" pattern
8. A reusable manual checklist

Automated tools (which we'll cover in lesson 06-02) detect only 30-40% of problems: they can see that an alt is missing, but not whether the alt text makes sense. Manual testing covers the human judgement no machine has: is the focus order logical? does the accessible name describe what the button does? is the visible focus actually visible? And you don't need anything beyond what's already on your machine.

The mental rule: if you can't use the page with a keyboard and a screen reader, neither can your user.

Put the mouse in a drawer. Many users (Lucía, with reduced mobility) navigate with the keyboard only. The essential keys:

Open the "Python from scratch" course page and, without touching the mouse, check:

• Visible focus: on each Tab, can you clearly see where the focus is? If the design used outline: none with no replacement, this is failure number one (WCAG 2.4.7 Focus Visible; and 2.4.11 Focus Not Obscured in WCAG 2.2).
• Logical order: focus should follow the reading order: header → breadcrumbs → title → "Enroll" button → description/syllabus/reviews tabs → footer. A positive tabindex usually breaks it.
• No keyboard traps: enter the video player or the enrollment modal. Can you get out with Tab or Esc, or do you get "trapped"? (WCAG 2.1.2 No Keyboard Trap).
• Skip link: when you press Tab right after the page loads, does a "Skip to content" link appear? It should become visible on focus and take you to <main>.
• Operating the catalog filter: the category checkboxes and the level selector should be toggled with Space/arrow keys and applied without a click.
• Operating the enrollment modal: when it opens, focus should move into the modal; Esc closes it; and focus should return to the button that opened it.

Tip: walk through the whole page twice, forwards and backwards. Many traps only show up with Shift+Tab.

You don't have to be an expert to catch big problems. Marta uses NVDA every day; you can fire it up for 10 minutes and learn a lot.

• Windows: install NVDA (free, nvaccess.org). Start it with Ctrl+Alt+N. The Insert key is the "NVDA key".
• Mac: VoiceOver is already included. Turn it on with Cmd+F5. The Ctrl+Opt combination is the "VO key".

Basic commands for developers:

• Navigate by headings (H): is the <h1> the course title? Does the hierarchy step down logically (h1 → h2 → h3) with no skips?
• Navigate by landmarks (D): are banner, navigation, main, and contentinfo announced?
• Go to the "Enroll" button: does NVDA read a clear accessible name ("Enroll in Python from scratch, button") or just a bare "button"?
• Listen to the images: does the alt on the instructor's photo sound natural, or does it say "IMG_2043.jpg"?
• Open the syllabus accordion: when it expands, does it announce "expanded/collapsed"? Here you check the aria-expanded from Module 5 actually sounding out.

Close your eyes for a minute and try to complete the enrollment by ear alone. It's uncomfortable, and that discomfort is exactly the finding.

Sofía has low vision and browses with zoom. Two distinct checks:

• Browser zoom to 200% (Ctrl/Cmd + +): WCAG 1.4.4 (Resize Text) requires text to scale to 200% with no loss of content or functionality. Push it all the way to 400%.
• Reflow at 320px (WCAG 1.4.10 Reflow): shrink the window to 320 CSS px wide (or zoom to 400% at 1280px) and check that no horizontal scroll appears and that nothing overlaps or gets cut off. Content should "reflow" into a single column.

What typically fails in Cursalia: the filter bar that spills off to the right, the price overlapping the button, or text in fixed pixels that won't grow. If you have to scroll in two directions to read a paragraph, that's a failure. (How to fix it—relative units, media queries—is in Module 4.)

You don't need anything external: the browser already inspects the accessibility tree (the one we saw in Module 2).

• Chrome/Edge: DevTools → Elements tab → Accessibility panel. Select the "Enroll" button and read its Computed name, its Role, and its states. That's where you see whether the accessible name you heard in NVDA comes from the text, from an aria-label, or from a <label>.
• Firefox: DevTools → Accessibility tab. It has built-in contrast and keyboard checks, and shows the tree as a navigable list.

Check the heading and landmark structure visually: a tree with a single main, a unique h1, and a hierarchy with no skips. If the tree shows a button "with no name" (empty name), you've just found what sounded like a bare "button" in NVDA.

For a one-off case—the price in light grey on white, the button text—there's no need to scan the whole page. Use the contrast eyedropper in DevTools (Chrome shows the ratio when you inspect color, with a ✓/✗ against AA/AAA) or a color picker that gives you the ratio. Remember the thresholds from Module 4:

• Normal text: 4.5:1 (AA).
• Large text (≥24px, or ≥18.66px bold): 3:1 (AA).
• UI components and focus states: 3:1 (WCAG 1.4.11 Non-text Contrast).

When a team is in a hurry, the same things almost always fall first. Keep them on your radar:

1. Visible focus removed (outline: none "because it looked ugly").
2. Buttons with no accessible name (icons with no text: the search magnifier, the close X).
3. Images with empty or junk alt on informative images.
4. Broken focus order from positive tabindex values or from shuffling the visual order with CSS.
5. Modal with no focus management (doesn't enter, doesn't trap, doesn't return).

If you only have 15 minutes, review these five: they affect the most users for the least effort.

Save this checklist as a template: it's your first line of defence before you touch any automated tool.

• Reaching for the mouse "out of habit": if you touch the mouse, you're no longer doing keyboard testing. Be strict.
• Confusing "me, a developer, using NVDA" with "a real NVDA user": you know where everything is. This catches technical faults, not usability ones (that's lesson 06-03).
• Testing only the "happy path": also test form errors, empty states, and the modal opened/closed several times.
• Trusting focus in a single browser: visible focus and reflow vary; check at least Chrome and Firefox.
• Tip: automate the repetitive stuff (06-02) and save your manual time for judgement (order, names, the sense of the alt).

Exercise 1. You Tab through the Cursalia course page and notice that, when the enrollment modal opens, focus does not move into it and stays behind, on the page. Which WCAG criterion is violated, and who does it affect most?

Exercise 2. With NVDA you navigate by headings (H) in the catalog and hear: h1, then h3, then h2. What's the problem, and why does it matter for Marta?

Exercise 3. Design a 15-minute mini-session to review the Cursalia video player with keyboard and screen reader only. List 4 concrete checks.

Solution 1. It violates 2.4.3 Focus Order (and the modal pattern's focus management from Module 5): when the modal opens, focus should move to it. It affects Lucía (keyboard-only) and Marta (screen reader) most, as they're left "outside" the dialog without knowing it has opened. The fix is in the modal pattern from Module 5.

Solution 2. There's a heading level skip (h1 → h3 → h2): the hierarchy is inconsistent. It violates the correct use of headings (1.3.1 Info and Relationships). Marta uses headings as an index to jump around the page; a broken hierarchy gives her a wrong mental map of the structure.

Solution 3. Example: (1) Can you reach the Play button with Tab and activate it with Enter/Space? (2) Are the controls (volume, captions, timeline) keyboard-operable and do they announce their name in NVDA? (3) Does the captions button announce its on/off state? (4) Is focus visible on the controls and not trapped inside the video?

Manual testing is your cheapest and most honest safety net: with keyboard, screen reader, zoom, and DevTools you catch most serious problems before writing a single line of test. But it's slow and depends on your discipline. In the next lesson, 06-02 Automated Testing Tools, we'll see how to hand the repetitive, objective part off to machines—always remembering that automation covers only 30-40% and never replaces what you've just learned here.