06-02 made the ceiling of automation clear: 30-40% of problems, and only the objective ones. And in 06-01, when you fired up NVDA for 10 minutes, we already flagged something uncomfortable: you know where everything is. You close your eyes, but you carry the map of the page in your head. Neither the machine nor the developer testing can see what really matters in the end: whether a person who uses that technology every day, and who doesn't know your site, can complete their task without getting frustrated. That's usability, and it's the definitive validation. In this lesson you'll learn to plan, moderate, and get the most out of testing sessions with real users of assistive technologies on Cursalia.

1. "I test with an AT" is not "a real user of that AT tests"
2. Planning a session
3. Recruitment, consent, and ethics
4. Moderating without ruining the results
5. What to observe and measure
6. Scenarios in Cursalia: Marta, Lucía, and Sofía
7. Combining with expert review
8. The "we tested with one person" trap

This is the central distinction of this lesson:

An example: in 06-01 you, with NVDA, "found" the Enroll button because you knew it existed. Marta, a real blind user, navigates by headings looking for where to enroll, doesn't find it where she expects, and concludes the course "can't be bought yet". Technically the button had an accessible name and passed axe. In usability terms, it was invisible. No other test produces that finding.

A good session is prepared before you sit anyone down.

• Objectives: define what you want to learn. Not "test accessibility" (too vague), but "can a screen reader user complete an enrollment unaided?".
• Realistic tasks: give tasks, not instructions. Bad: "click the blue button in the top right". Good: "Find a Python course and enroll in it." The task describes a goal, not the steps: that way you observe how the person decides the path.
• Task script for Cursalia (example):
  1. Find a Python course for beginners using the catalog.
  2. Find out how long it lasts and who teaches it.
  3. Enroll (complete the enrollment form).
  4. Open the player and turn on the captions for the first lesson.
  5. Answer the lesson 1 quiz from the student dashboard.
• Duration: 45-60 minutes per person is comfortable; more than that is exhausting.
• Environment: have the person use their own equipment and their own AT configuration whenever possible. The speech rate, the browser, and the version are their world; recreating them yourself distorts the results.

You're inviting people, not collecting data from a server. Respect is part of the method.

• Recruitment: find participants through disability associations, specialized panels, or community networks. You need real, regular users of the AT, not colleagues in disguise.
• Incentives: pay the participants. Their time and experience are expert work; a fair incentive is a matter of dignity, not an extra.
• Informed consent: explain in writing what you're going to do, what you'll record (screen, voice, screen reader audio), what it will be used for, and how long you'll keep it. Sign before you start. The person can stop whenever they want, without giving a reason.
• Ethics and respect in the room:
  • You're testing the product, not the person. Say it out loud: "if something doesn't work, it's our website's fault, not yours".
  • Use respectful, person-centered language; ask how they prefer you refer to their disability if it comes up.
  • Never turn the session into a spectacle or "inspiration". It's product research.
  • Privacy: anonymize the findings in the report (Module 06-04). "Participant 3, an NVDA user", not their name.

The moderator can wreck the session with a single sentence. Golden rules:

• Think-aloud protocol: ask the person to narrate what they do, look for, and expect. "Now I'm looking for the enrollment button… I can't hear it… I'll try by headings." That narration is pure gold.
• Don't over-help: when they get stuck, bite your tongue. The awkward silence is where the finding appears. If you help at the first hesitation, you've erased exactly what you came to measure. Only step in if they've been blocked for a long time and the frustration is no longer adding anything.
• Don't steer: no "try pressing Tab there" or "can't you see the blue button?". Neutral questions: "what did you expect to happen?", "what are you trying now?".
• Observe, don't interrogate: during the task, stay quiet and take notes. Save the questions for the end of each task.
• Watch out for courtesy bias: people tend to say things are "fine" so as not to offend. Push on the negative: "what did you find most annoying?".

Combine quantitative metrics with qualitative observations (the latter are usually what changes the product).

Time and success make headlines; quotes and blocking points produce the remediation tasks of 06-04.

Three real sessions, three findings that neither automation (06-02) nor the developer's manual testing (06-01) had caught.

Task: enroll in a Python course. Marta fills in the enrollment form and presses "Confirm". A visual success message appears, but it's injected into a container with no aria-live, so NVDA doesn't announce it. Marta is left waiting in silence, not knowing whether she's enrolled, and ends up reloading the page for fear of having paid twice.

• Why it slipped through: axe saw the message present in the DOM (passes). You, in 06-01, saw the message with your eyes and marked the task as done. Only someone who depends on the audio reveals that the message doesn't exist for her. (The how to fix it—live regions—is dynamic content in Module 7.)

Task: apply the "beginner level" filter in the catalog. Lucía reaches the checkboxes with Tab, but the catalog applies the filter with an onchange that also moves focus to the top of the results list. Because she uses the keyboard exclusively and every action sends her back to the top, she takes three times as long and gets disoriented. Functionally it "works"; in practice it's exhausting.

• Why it slipped through: it's not a violation of any automated rule or a technical focus fault (focus is managed, just badly for her flow). It's pure effort cost, visible only by watching someone who navigates this way all day.

Task: read the price and press Enroll. At 300% zoom, the "Enroll" button stays fixed (position: sticky) and covers the price just as Sofía scrolls to read it. The reflow from 06-01 passed (there was no horizontal scroll), but the overlap of two elements when zoomed in only shows up when someone at her real zoom level tries to use the page.

• Why it slipped through: automated contrast and reflow came back green; the finding is an interaction between zoom, scroll, and a sticky element that no tool models.

Three people, three serious usability problems, zero detected by axe or the developer's manual testing. That's the argument of this lesson.

You won't always be able to recruit users for every iteration. A valuable complement is expert review (heuristic evaluation): a person experienced in accessibility walks through Cursalia applying WCAG and their knowledge of how people with disabilities use the web. It doesn't replace real users—an expert still isn't Marta—but it catches a lot between sessions and helps decide what to bring to the next user session. The ideal order: automated (06-02) → manual + expert (06-01) → real users (06-03).

A serious mistake: running a session with one blind user and declaring "Cursalia is accessible for blind people". Disabilities are diverse, and so is the variation within each type:

• Different disabilities (visual, motor, hearing, cognitive) → completely different problems. Marta, Lucía, Sofía, Diego, and Hugo each trip over different things.
• Different AT and configuration → NVDA, JAWS, and VoiceOver don't behave the same; two NVDA users may use different shortcuts.
• Different experience → a veteran user overcomes obstacles that sink a novice.

Practical rule: include several participants per profile and cover a diversity of disabilities (not just screen readers; also keyboard, zoom, cognitive, and deafness). With 3-5 users per profile, most of the serious problems for that profile already surface. A single person gives you anecdotes, not evidence.

• Giving the steps instead of the task: if you say "press the second button", you no longer observe how the person searches. Give goals, not routes.
• Helping at the first hesitation: kills the finding. Sit with the silence.
• Mistaking yourself for a user: you know the site; your NVDA testing (06-01) is valid for the technical side, not for usability.
• One person = "it's been tested": false. Diversify profiles and AT.
• Not paying / treating it as a favour: it's expert work; the incentive is respect, not optional.
• Forgetting consent and anonymity: recording without permission or publishing names is a serious ethical failing.
• Tip: record (with permission) and review afterwards; live, you miss details of the screen reader audio.

Exercise 1. Marta completes the enrollment form, presses "Confirm", and is left in silence, reloading the page. axe reported nothing and you, in 06-01, marked the task as passed. What kind of problem is it, why did only she detect it, and how does it differ from a fault a tool would catch?

Exercise 2. Your boss says: "We ran a session with one JAWS user and it all went fine, we can put the accessible seal on it now." Give two reasons why that conclusion is invalid.

Exercise 3. Design a 45-minute session with Lucía (keyboard only) to validate the Cursalia enrollment flow: write (a) 3 realistic tasks, (b) 2 metrics you'd collect, and (c) one moderation rule you'd force yourself to follow.

Solution 1. It's a usability problem, not a technical violation: the success message exists in the DOM (which is why axe passes and you see it), but it isn't announced to someone who depends on the audio. Only Marta detects it because only she depends on the reader to know the action took effect; for you the problem is invisible because you get the information another way (sight). It differs from a tool fault in that here no checkable attribute is missing: it's the experience that fails, and no automated rule models that.

Solution 2. (1) One person is not evidence: their problems and their skill are particular; you need several users per profile (3-5) for the serious problems to surface. (2) Diversity is missing: a JAWS user doesn't represent keyboard users, zoom users, people with dyslexia, or people with deafness; "accessible" requires covering different disabilities and different AT, not a single profile.

Solution 3. Example. (a) Tasks: "Find a Python course for beginners"; "Enroll in it"; "Turn on the captions for the first video"—all as goals, without specifying keys. (b) Metrics: task success (completed/with help/failed) and the number of times focus sends her back to the top of the list when filtering (friction point). (c) Moderation rule: don't suggest keys or point out where a control is; when she gets stuck, wait in silence and, at most, ask "what are you trying now?".

Testing with real users of assistive technologies is the definitive validation: only it reveals usability, that layer neither the 30-40% of automation (06-02) nor your developer manual testing (06-01) reaches. Marta, Lucía, and Sofía taught us three problems invisible to everything else. But a session generates many scattered findings—quotes, times, blocking points, violations—and you have to turn them into decisions: what's serious, what's a false positive, what gets fixed first, and how you prove it's resolved. That's what the module's final lesson is about, 06-04 Interpreting Accessibility Reports: reading everything you've collected across the three previous lessons and turning it into a prioritized action plan.