We close Module 1 with one idea: before we apply a single WCAG criterion, we need to understand the people we design for. That is the first step. In this lesson we'll survey the disabilities that matter for the web, grouped by the kind of ability affected: visual, auditory, motor/physical, cognitive and learning, speech, and neurological. For each group we'll look at what it involves and, above all, what barriers that person runs into on a poorly built website -described at a high level, without the technical fix yet. We'll bring back the permanent / temporary / situational model from lesson 01-02 and apply it to each group, then ground it in concrete scenarios of people using Cursalia.

Two words about scope. First: here we describe the people and their barriers, not the tools they use (screen readers, magnifiers, and so on are lesson 02-02) nor how they navigate with them (02-03). Second: we will not give the code solution; the "how to fix it" is Modules 3, 4, and 5. Here we build the empathy and the diagnosis that will give meaning to everything else.

1. Why group disabilities (and a caveat)
2. Visual disabilities
3. Auditory disabilities
4. Motor and physical disabilities
5. Cognitive and learning disabilities
6. Speech disabilities
7. Neurological and other disabilities
8. The permanent / temporary / situational model applied

We group disabilities by affected ability because that's the most useful lens for design: what matters to us as web creators isn't a medical diagnosis but which interaction channel is limited (seeing, hearing, moving, processing, speaking) and, therefore, which barriers we must avoid.

Before we start, three essential caveats:

• They aren't watertight compartments. One person can belong to several groups (for example, deafblindness, or an older person with low vision and a hand tremor).
• There's an enormous spectrum of degrees. "Visual disability" spans everything from a mild difficulty with contrast to total blindness. Most people sit somewhere in between.
• We use person-first language. We say "a blind person" or "a person with low vision," not labels that reduce someone to their condition. Respect is part of the design too.

They affect the visual channel, the one most used to consume the web. Within the group there are very different realities:

• Blindness. Total or near-total absence of sight. These people perceive nothing on the screen: they access content through hearing (audio) or touch (braille), by way of assistive technologies. Purely visual design is invisible to them.
• Low vision. Greatly reduced vision that cannot be corrected with glasses: low acuity, a reduced field of vision (tunnel vision or central loss), sensitivity to glare. They usually rely on sight but need to enlarge, boost contrast, or reorganize the content.
• Color blindness and color-perception deficiencies. The person can see but cannot tell certain colors apart (most commonly, confusing reds and greens). It affects around 8% of men.

Typical barriers on the web (at a high level):

• Images, icons, or graphics with no text alternative: for a blind person, they simply don't exist.
• Insufficient contrast between text and background: illegible for low vision.
• Text that can't be enlarged without breaking the page, or that forces horizontal scrolling.
• Information conveyed by color alone: "the fields in red are required," "the course in green is available." Anyone who can't tell the colors apart loses the message.
• Interfaces that rely on visual position or shape with no label to name them.

Cursalia scenario. Marta is blind and wants to sign up for a course. In the catalog, each course is a card with an attractive image and a button. If those images have no description and the button is just called "See more" repeated forty times, Marta hears a list of "See more, See more, See more..." with no idea which course each one belongs to. The barrier isn't her blindness: it's the design.

They affect the auditory channel. With the web becoming ever more audiovisual (video lessons, podcasts, sound notifications), their impact has grown.

• Deafness. Profound or total hearing loss. Many deaf people communicate in sign language, which is their native language; written text in the spoken language can be a second language for them, which is worth remembering when writing.
• Hard of hearing. Partial hearing loss. The person may hear something, perhaps with hearing aids, but misses nuances, words in noisy settings, or low-quality audio.

Typical barriers on the web:

• Video without captions: all the spoken content is lost.
• Audio or podcasts without a transcript: there's no alternative way to reach the message.
• Important information given by sound alone (an alert that "beeps" when a form is submitted) with no visual equivalent.
• Videos with poor-quality auto-generated captions, full of errors, that confuse more than they help.

Cursalia scenario. Diego is deaf and watches a video lesson in Cursalia's player. The instructor explains a key concept talking to the camera. With no captions or transcript, Diego sees a person moving their lips for twelve minutes: the educational content, which is what he paid for, is inaccessible to him.

They affect the ability to move and operate input devices (mouse, keyboard, touchscreen). They're highly varied:

• Limited mobility in the hands or arms (from spinal injury, paralysis, arthritis, sclerosis, and so on).
• Tremor or lack of precision (Parkinson's, essential tremor): makes it hard to aim and click on small targets.
• Amputation or absence of limbs.
• Inability to use the mouse, whether because of the above or fatigue; many of these people navigate with the keyboard alone or with alternative devices.

The common thread in this group: precise, fast interaction is difficult or impossible, and the mouse is often ruled out.

Typical barriers on the web:

• Functions that only work with the mouse (menus that open "on hover," drag-and-drop with no alternative): anyone navigating by keyboard is shut out.
• Tiny or tightly packed touch or click targets: impossible to hit with a tremor.
• Time limits for completing tasks (a form that "expires") that leave no room for someone who moves more slowly.
• Chaotic navigation order: if pressing Tab sends the focus jumping around illogically, moving through the page becomes exhausting.

Cursalia scenario. Lucía has a spinal injury and navigates with the keyboard alone. She wants to enroll. She reaches the form by tabbing, fills in the fields... but the dropdown to choose the payment method only opens on a mouse click, and the final "Confirm enrollment" button doesn't receive keyboard focus. Lucía makes it to the last step and can't finish. (We'll see this scene in depth in 02-03.)

This is the broadest and most diverse group, and often the most overlooked because it's "invisible." It affects how information is processed, understood, remembered, or attended to. Some examples:

• Dyslexia. Difficulty with reading and processing text (not with intelligence). Long blocks, cramped or justified typefaces make it worse.
• ADHD. Difficulty sustaining attention; distracting elements (animations, carousels, moving ads) are especially harmful.
• Autism (ASD). May involve sensitivity to stimuli (sounds, motion, visual clutter) and a preference for literal, predictable language; metaphors or inconsistent interfaces cause confusion.
• Memory problems (including age-related decline): make it hard to remember steps, codes, or information across screens.
• Dyscalculia. Difficulty with numbers: dates, prices, codes, calculations.

The common thread: cognitive effort matters. A cluttered interface, with complex language or unpredictable steps, excludes these people even if it technically "works."

Typical barriers on the web:

• Dense text and jargon: convoluted instructions, endless paragraphs.
• Distractions: content that moves, blinks, or plays on its own.
• Long, unguided processes: many-step forms with no indication of where you are.
• Cryptic error messages ("Error 0x24B") that don't explain what to do.
• Lack of consistency: the same button moving or changing its name from page to page.

Cursalia scenario. Hugo has dyslexia and ADHD. He takes an interactive quiz in the course. The questions are written with double negatives and very long sentences, and a promotional banner blinks off to the side. Hugo rereads each question three times and keeps losing focus: he fails not because he doesn't know the material, but because of how it's presented.

They affect the ability to produce clear speech (muteness, stuttering, the aftereffects of a stroke, use of an artificial larynx). On the web they used to have little impact... until the arrival of voice interfaces: assistants, dictation, voice authentication, customer support that "only works by phone."

Typical barriers on the web:

• Services that require speaking as the only method (for example, voice verification) with no written alternative.
• Phone-only support with no chat, email, or form.
• Assuming that everyone can use voice commands.

Cursalia scenario. Aisha can't speak clearly after an operation. She has a question about her enrollment and the only contact channel Cursalia offers is a phone number. If there were a chat or a support forum/form, Aisha could resolve her problem on her own.

Here we include conditions that don't fit neatly above but are highly relevant to the web:

• Photosensitive epilepsy. Certain flashes, flickers, or patterns on screen can trigger an epileptic seizure. It's one of the few barriers that doesn't just exclude but can cause real physical harm.
• Vestibular disorder / motion sensitivity. Large animations, parallax effects, or abrupt transitions can cause dizziness or nausea.
• Chronic fatigue and pain, which reduce the time and energy available for complex tasks.

Typical barriers on the web:

• Content that flashes more than three times per second (seizure risk).
• Large animations that are impossible to stop.
• No respect for the system's reduce motion preference.

Cursalia scenario. Nora has a vestibular disorder. Cursalia's landing page opens with a full-screen background video that keeps zooming and sliding through transitions. Within a few seconds Nora feels dizzy and closes the tab: she'll never make it to the catalog.

Let's bring back the model from lesson 01-02: almost every permanent limitation has temporary and situational equivalents that happen to anyone. Designing for the first also solves the other two, which is why accessibility benefits 100% of users. Applied group by group:

The key takeaway: when we add captions "for Diego" (deaf, permanent), we also help someone with an ear infection (temporary) and someone studying without headphones on the subway (situational). Accessibility isn't an edge case: it's the general case.

• Thinking only about blindness. It's the most-cited example, but total blindness is a minority within disabilities. Low vision, cognitive, and motor disabilities affect far more people and are frequently forgotten.
• Forgetting invisible disabilities. Dyslexia, ADHD, autism, or memory problems can't be seen, yet they hugely shape how people use the web.
• Ignoring the temporary and situational. It reduces accessibility to "a minority" and weakens the case. We will all be users with some limitation at some point.
• Using stigmatizing language. Prefer person-first language ("a person with a disability," "a blind person") over reductive labels.
• Tip: for every Cursalia surface, ask yourself "what if the user can't see / hear / use the mouse / process complex text?" Those four questions cover most barriers.

Exercise 1. Classify each situation into the affected disability group (visual, auditory, motor, cognitive, speech, or neurological) and state the specific barrier:

1. A user can't tell which form fields are marked as required because they're only flagged in red.
2. A user gets intense dizziness on entering the landing page because of an animated background.
3. A user can't press the small "Confirm" button because their hands are shaking.

Exercise 2. For Cursalia's video-lesson player, name one barrier affecting: (a) a deaf person, (b) a blind person, (c) a person with ADHD.

Exercise 3. Take the barrier "the catalog conveys a course's availability by color alone (green = seats open, red = full)." Apply the permanent/temporary/situational model: give one beneficiary of fixing it in each category.

Solution 1.

1. Visual (color blindness): the information is given by color alone; anyone who can't distinguish red doesn't know which fields are required.
2. Neurological (motion sensitivity / vestibular): the background animation causes dizziness and can't be stopped.
3. Motor (tremor): the click target is too small to hit without precision.

Solution 2. (a) Deaf: the video has no captions or transcript, so all the spoken content is lost. (b) Blind: the player controls (play, volume) aren't labeled or can't be used without sight, and there's no description of what's happening on screen. (c) ADHD: distracting elements around the video (moving banners, autoplay of the next one) make it hard to stay focused.

Solution 3. Fixing the "color only" issue (by also adding a text label such as "Full") benefits: permanent = a person with color blindness; temporary = someone with eye strain who perceives color nuances poorly that afternoon; situational = someone checking the catalog on their phone in sunlight, where the colors wash out.

We've walked the human map of accessibility: visual, auditory, motor, cognitive, speech, and neurological disabilities, what each group involves, and the barriers it meets on the web -always at a high level, because the "how to fix it" arrives in Modules 3 to 5. We've seen that almost none of these is an edge case: the permanent / temporary / situational model shows that designing for these people improves everyone's experience, and we've illustrated it with Marta, Diego, Lucía, Hugo, Aisha, and Nora in Cursalia.

But these people don't access the web bare-handed: they rely on tools that translate the content into a channel they can actually use -voice, braille, magnification, voice commands. Those tools are the assistive technologies, and they're the subject of the next lesson, 02-02: Overview of Assistive Technologies. Knowing them is essential, because our code will have to "talk" to them.