We now know who they are (02-01) and which tools they navigate with (02-02). We're missing the piece that turns all of that into design decisions: how people actually navigate with those assistive technologies, and why that shapes how we must build each page. This is the lesson that "closes the loop" of the module: here you'll see that AT doesn't consume the web the way you do, but by following very specific patterns -by keyboard, by structure, by voice, with zoom- and that if the site ignores those patterns, the experience breaks at identifiable points.

We'll go through four usage patterns, and then narrate three complete scenarios in Cursalia (Marta with NVDA, Lucía with the keyboard alone, and a student with zoom at 300%), showing where and why it fails when the site isn't well built. We'll use a minimal HTML fragment or two to illustrate good versus bad structure, but without going into the full implementation (semantics and ARIA are covered in Module 4). The goal here is to motivate the why; the how comes in the following modules.

1. Pattern 1: keyboard navigation
2. Pattern 2: screen-reader use by structure
3. Pattern 3: voice navigation
4. Pattern 4: zoom, magnification, and reflow
5. Scenario A - Marta searches for a course with NVDA
6. Scenario B - Lucía enrolls with the keyboard alone
7. Scenario C - Sofía studies with zoom at 300%
8. What all the failures have in common

A great many people don't use the mouse: motor users, screen-reader users, switch users, voice users... and power users too. They all share one language, that of the keyboard. Its basic keys:

From this pattern come three requirements we'll repeat all course long:

• Everything operable with the mouse must be operable with the keyboard. If a menu only opens "on hover" or a button only responds to a click, keyboard users are shut out.
• The focus must be visible. The person needs to know where they are -where the "keyboard cursor" is. That box or highlight is the visible focus. If the design removes it (CSS that strips the outline), the user navigates blind.
• The focus order must be logical. Tab should move through the page in an order that makes sense (usually the reading order). If it jumps from the heading to the footer and then to the menu, moving through the page becomes a maze.

Here's the revelation that most changes a developer's mindset: a blind person doesn't read the page top to bottom, word by word. That would be painfully slow. Instead, they navigate by structure, using the markup as an index. Their usual shortcuts:

• Jump by headings (in NVDA/JAWS, the H key): they move through the <h1>, <h2>, <h3>... like someone skimming a newspaper's headlines to get oriented.
• Links list: they ask "give me all the links" and choose. That's why forty links called "See more" are useless: out of context, they don't say where they go.
• Regions / landmarks: they jump straight to zones such as "main navigation," "main content," "footer," if the site declares them.
• Browse mode vs. focus mode. This nuance is key. When reading, the reader is in browse mode (or "exploration mode"): keys like H or the arrows serve to move through the content. But on reaching a form field, the reader switches to focus mode (or "forms mode"): now the keys type into the field instead of navigating. Many readers switch between the two modes automatically as you enter and leave fields.

The design consequence is enormous: semantic structure is the interface for the screen-reader user. Compare these two Cursalia catalogs:

In the first case, the user presses H to jump by headings and nothing happens: there are no headings; the site is a flat wall. They ask for the links list and hear "See more," with no destination. In the second, they jump from <h2> to <h2> hearing the course names, and each link is announced with its destination. Same visual appearance; opposite experience. (The detail of why <h2> and <article> are the right choices, and how to label them, is Module 4; here we only observe the effect.)

Someone using voice control operates the page by speaking. Their most typical commands:

• Activate by name: "click Enroll," "press Search." The system looks for an element whose accessible name matches what was said.
• Show numbers / grid: when an element has no pronounceable name (a "🔍" icon with no label), the person says "show numbers" and the system overlays a number on each clickable element; they then say "click 7." It's the plan B, slower and clumsier.
• Dictation and scrolling: "scroll down," "go back to the top," dictating text into a field.

The design lesson: the visible name should match the accessible name. If the button says "Enroll" on screen but is internally named something else (or nothing), the command "click Enroll" fails, and the person doesn't even know why. Unlabeled icons force people to fall back on numbers, making every action more costly. (How to guarantee that accessible name: Modules 4 and 5.)

A person with low vision magnifies. We're not talking about a rare case: magnification of 200% is an everyday thing, and with magnifiers people reach 300-400%. At such magnification, very few words fit on a screen, so the correct behavior is reflow: the content reorganizes into a single column read by scrolling vertically, with no horizontal scrolling.

Where it breaks:

• Horizontal scrolling: if a horizontal bar appears when magnifying, the person has to drag left and right on every line to read. It's exhausting and causes chunks to be missed.
• Content that overlaps or gets cut off: menus that cover the text, buttons that run off the screen, clipped text.
• Fixed bars that eat the screen: a fixed header that at 300% takes up half the screen and leaves the content in a sliver.

The principle: the design must be flexible/responsive so the same content fits when reorganized. It's the same quality that makes a site work well on mobile; that's no coincidence. (The exact resize and reflow criteria belong to Module 4.)

Marta is blind and uses NVDA on Windows. She wants to find the "Python from scratch" course in Cursalia's catalog and open its page.

How she tries (her natural pattern): when the catalog loads, Marta presses H to jump by headings and quickly map the page. Then she'd ask for the links list to go straight to the course.

Poorly built site:

1. She presses H... and NVDA says "no headings." The whole page is a sea of <div>. Marta has lost her map: now she has to hear the entire page, linearly.
2. She asks for the links list and hears "See more, See more, See more..." forty times, all identical. There's no way to tell which one is Python.
3. The cards carry a course image with no alt text: NVDA reads "image" or the file name, course_0423.jpg. Useless.
4. Marta gives up and moves to another platform. The barrier wasn't her blindness; it was the lack of structure and alt text.

Well-built site:

1. She presses H and hears "Course catalog, heading 1," "Python from scratch, heading 2," "UX Design, heading 2"... In seconds she has the mental index.
2. She lands on "Python from scratch" and its link is announced as "See the Python from scratch course, link." She presses Enter and goes in.
3. Total: a few seconds, with autonomy and no frustration.

Lucía has a spinal injury and navigates with the keyboard alone (no mouse). We pick up the scene we left open in 02-01: she wants to complete the enrollment form.

How she tries: Tab to move field by field, type, arrows to choose options, Enter to submit.

Poorly built site - it breaks at three points:

1. Invisible focus. Someone "cleaned up" the design by removing the outline in the CSS. Lucía presses Tab several times and can't see where she is: she types blind, not knowing which field she's writing in.
2. Keyboard trap + mouse-only dropdown. The "payment method" selector is a custom <div> that only opens on a click. It won't expand with the keyboard and, worse: as she tabs, the focus gets trapped inside it and won't leave (a keyboard trap). Lucía can neither choose a payment method nor continue.
3. Unreachable final button. Even getting past the above, the "Confirm enrollment" button is a <div onclick> that doesn't receive focus with Tab. Lucía reaches the last step and can't press it. Enrollment lost.

Well-built site: each field receives focus in a logical order, the focus is clearly visible, the payment selector opens and is navigated with the keyboard (arrows + Enter), and "Confirm" is a real <button> that Lucía activates with Enter. She enrolls on her own, unaided. (The how of building that accessible selector is Module 5; the semantic button, Module 4.)

Sofía has low vision and navigates with the browser zoom at 300%. She's on the course page reading the syllabus before enrolling.

Poorly built site:

1. At 300%, the page keeps its compressed three-column grid: horizontal scrolling appears. Sofía has to drag left and right on every line of the syllabus. After two minutes, exhausted, she quits.
2. The fixed header now takes up almost half the screen; the actual content peeks through a sliver.
3. A "limited seats" notice is cut off by the edge: Sofía can't read it in full.

Well-built site: on magnifying, the content reflows into a single column; Sofía reads by scrolling vertically, with no horizontal scrolling, the header compacts, and nothing overlaps. Same information, minimal effort.

If you look at the three scenarios, the failures aren't random: they recur and cluster. And that clustering is, precisely, the run-up to Module 3.

• Marta not perceiving the images or being able to read the catalog → it's a Perception failure.
• Lucía not being able to tab, not seeing the focus, or getting trapped → it's an Operability failure.
• Hugo (02-01) not understanding the questions or the errors → it's an Understanding failure.
• A <div onclick> not registering as a button in the accessibility tree → it's a Robustness failure.

Perceivable, Operable, Understandable, Robust. Those four buckets are no coincidence: they're the four POUR principles of WCAG that we introduced in lesson 01-04. We've just discovered, from the real experience of people, why the standard is organized exactly this way.

• Believing people read the web the way you do. The screen-reader user jumps by structure; the keyboard user tabs; the low-vision user magnifies. Designing for a linear, mouse-driven path leaves all of them out.
• Removing the visible focus "because it's ugly." It's one of the most frequent and most serious harms: it leaves Lucía navigating blind. Never remove the focus indicator without replacing it with a better one.
• Building buttons and controls with <div>. They seem to work with the mouse, but they don't receive focus, don't respond to Enter/Space, and don't register in the accessibility tree. It's the root of half of Module 2.
• Links and buttons with no meaningful text. "See more," "Here," unlabeled icons: out of context they say nothing to the screen reader or voice control.
• Testing only with mouse and sight. Tip: navigate a complete Cursalia task using only Tab, Enter, and the arrows, without touching the mouse. In five minutes you'll find barriers that aren't visible at a glance.

Exercise 1. A Cursalia developer says: "I tested the catalog with the mouse and it works great, so it's accessible." Give three reasons, based on the patterns in this lesson, why that test is insufficient.

Exercise 2. In Lucía's scenario we identified three break points (invisible focus, keyboard trap, non-focusable button). Classify each one by the POUR principle it corresponds to and explain in one sentence why.

Exercise 3. Sofía magnifies to 300% and horizontal scrolling appears. (a) Which usage pattern is failing? (b) What behavior should the page have instead? (c) Which POUR principle does this problem belong to?

Solution 1. Examples: (1) They didn't test with the keyboard: a user who only tabs might not reach cards or buttons that do work with the mouse. (2) They didn't test with a screen reader: with no headings or meaningful link text, Marta can't navigate by structure even if it "looks fine with the mouse." (3) They didn't test with voice or zoom: unlabeled icons break voice control, and magnification to 200-300% could cause horizontal scrolling. In short, "works with mouse and sight" only covers one of the many usage patterns.

Solution 2.

• Invisible focus → Operable. The keyboard user can't operate the interface confidently if they don't know where the focus is.
• Keyboard trap → Operable. If the focus gets trapped, the person can't continue the operation; it's a total block of operability.
• Non-focusable button (<div onclick>) → Robust (and Operable). It doesn't register as a button in the accessibility tree (robustness toward AT) and, on top of that, can't be activated with the keyboard (operability).

Solution 3. (a) The zoom/magnification and reflow pattern fails. (b) The page should reorganize the content into a single column (reflow) so it can be read by scrolling vertically, with no horizontal scrolling. (c) It belongs to the Perceivable principle (that the user can perceive the content when magnifying it, without it being lost or made inaccessible).

We've seen how the web is actually used with assistive technologies: by keyboard (with visible focus and a logical order), by structure with the screen reader (jumping by headings, links, and regions, switching between browse mode and focus mode), by voice (activating elements by their name), and with zoom (expecting reflow with no horizontal scrolling). And in Cursalia we've seen, with Marta, Lucía, and Sofía, where and why the experience breaks when the site ignores those patterns.

With this we close Module 2. We now understand the people, their tools, and their ways of navigating. And we've made a discovery that ties it all together: the failures aren't random -they cluster into four families: they don't perceive it, they don't operate it, they don't understand it, it isn't robust. Those four families are the POUR principles of WCAG. They're not an academic abstraction: they're the systematic answer to the real barriers we've just witnessed.

That is exactly what opens Module 3: Principles of Accessible Design, where we'll develop Perceivable, Operable, Understandable, and Robust in depth. We'll no longer see them as a theoretical list, but as the ordered solution to the problems of Marta, Lucía, Sofía, Diego, and Hugo. Understanding the people was the prerequisite; from here on, we start designing the answer.