In the previous lesson we met the people and their barriers. Now we meet their tools. Marta (blind), Lucía (keyboard only), Diego (deaf), and the rest don't access the web bare-handed: they rely on programs and devices that translate the content into a channel they can actually use -voice, braille, magnification, spoken commands, a single button. Those tools are the assistive technologies (AT).

In this lesson we'll take a tour of the main ones: screen readers, magnifiers and zoom, braille displays, voice control, switch access, eye tracking, alternative keyboards, and the reading/high-contrast modes of the browser and the operating system. We'll also introduce, at a conceptual level, how an AT relies on the markup to work: this is where the idea of the accessibility tree and the accessibility APIs appears.

Scope: we describe what each AT is and who it's for, not how you program for it (that's semantics, ARIA, alt... Modules 4 and 5), nor the detailed navigation patterns (how you jump by headings, how focus mode works... that's lesson 02-03). Here we assemble the toolkit; the fine handling comes later.

1. What assistive technologies are
2. Screen readers
3. Magnifiers, zoom, and magnification
4. Braille displays
5. Voice control
6. Switch access
7. Eye tracking
8. Alternative keyboards and other input devices
9. Reading and high-contrast modes of the browser/OS
10. How AT "sees" your site: the accessibility tree
11. Map: disability → typical AT

An assistive technology is any product -software or hardware- that lets a person with a disability carry out a task that would otherwise be difficult or impossible. On the web, its job is to mediate between the page and the person: it takes the content, transforms it (into voice, large text, braille) and, in the other direction, translates the person's actions (a voice command, a switch press) into interactions with the page.

Two ideas worth fixing right away:

• AT doesn't guess. It works well only if the site gives it correct, structured information. A screen reader doesn't "understand" an image: it reads the description the developer gave it. This dependency is the whole reason this course exists.
• One person can combine several AT (for example, a screen reader + a braille display) plus operating-system settings (font size, reduce motion). There's no standard "AT user."

They're the best-known AT. A screen reader turns the content of the screen into synthesized speech and/or braille. It's used above all by blind people and some with severe low vision or reading difficulties. The person doesn't see the page: they hear it, element by element, and move through it with the keyboard or with touch gestures.

The main ones, with their usual platform:

One practical consequence of this table: there are many readers and none is identical to another. What sounds perfect in NVDA may read differently in VoiceOver. That's why, later on (Module 6), testing with more than one reader will be part of the process. For now, just remember that they exist, which platform they live on, and that they're free to try on nearly every system.

Not everyone with a visual disability is blind. Many have low vision and use their remaining sight magnified. There's a scale of solutions here:

• Browser zoom. The simplest and most universal: Ctrl + + (or Cmd + +) enlarges everything. Huge numbers of people use it every day, with or without a disability. Magnification of 200% is common; WCAG requires the page to keep working at that level.
• Operating-system magnifiers (Windows Magnifier, macOS Zoom): they enlarge a portion of the screen, sometimes with a lens that follows the cursor, up to 400% or more.
• Specialized software such as ZoomText or MAGic, which on top of magnifying also improve contrast, smooth edges, and can combine magnification with voice output.

The classic barrier this group faces: when the page is magnified and horizontal scrolling appears, or the content shifts out of place and overlaps. The correct behavior (content reorganizing into a single column, reflow) we'll see as a usage pattern in 02-03 and as a technical criterion in Module 4.

A braille display is a hardware device that connects to a computer or phone and represents text in tactile braille through a row of cells with pins that rise and fall. It works alongside a screen reader: the reader decides what text to show and the braille display materializes it under the fingers.

Why braille and not just voice? Because:

• It's essential for deafblind people, who can't use voice output.
• It lets you read spelling, code, figures, or proper names with precision where voice can make them ambiguous.
• Many blind people prefer braille for close reading (studying, reviewing) over the fast consumption of voice.

For us the implication is direct: everything the screen reader reads, the braille display transmits. If an image has no alt text, there's neither voice nor braille. In other words, improving things for the screen reader improves them for braille "for free."

Voice control lets you operate the device by speaking: dictating text and, above all, giving commands ("open the menu," "click Enroll," "scroll down"). It's used by people with motor disabilities who can't use a keyboard or mouse, and also by people with dyslexia or fatigue who prefer to dictate.

Common examples: Dragon (Dragon NaturallySpeaking / Dragon Professional) on Windows, Voice Control on macOS/iOS, and Voice Access on Android.

An important nuance we'll develop in 02-03: voice control usually relies on the visible or accessible name of the elements. If a button is really named "Enroll," the person says "click Enroll" and it works. If the button is an icon with no name, there's no word to say, and many systems then fall back on "show numbers" (overlaying a number on each clickable element) as a plan B.

Switch access is for people with very limited mobility who can only make one reliable gesture: pressing one or two buttons (a switch), operated with the hand, head, foot, or even a puff of breath. With so little input, how do you navigate an entire website?

Through scanning: the system highlights the elements one by one automatically, and the person presses the switch when the highlight reaches the element they want. It's like keyboard navigation taken to the extreme: underneath, it moves through the same focusable elements in the same order.

The consequence for design is blunt: if something isn't reachable by keyboard or the focus order is a mess, for a switch user it's not "inconvenient," it's literally unreachable, and every extra element in the path is time and effort. That's why the work we do for the keyboard (Module 5) directly benefits this group.

Eye tracking follows where the person is looking with a special camera and moves the pointer to that point; the "click" is made by holding the gaze for a moment (dwell) or with an auxiliary switch. It's used by people with very limited mobility (for example, ALS or quadriplegia) who retain control of their eyes.

Its great enemy is small, closely packed targets: aiming with the gaze is less precise than with the mouse, so tiny buttons or adjacent links become very hard to hit. It connects to the "touch target" barrier we already saw and to the target size criterion we'll cover later.

Not everyone uses the standard keyboard and mouse. There's an ecosystem of adapted hardware:

• Large keyboards, with spaced keys or a keyguard (for tremor or low precision).
• On-screen (virtual) keyboards, operated with the mouse, the gaze, or a switch.
• Trackballs, joysticks, and adapted mice for those who can't handle a normal mouse.
• Head/mouth sticks for typing key by key.

The key point: almost all of these devices, underneath, emulate a keyboard. That is, they generate keystrokes, Tab, Enter, arrows... That's why an idea we'll repeat throughout the course: if your site works perfectly with the keyboard, it works with the vast majority of these devices. The keyboard is the "lowest common denominator" of motor accessibility.

Not all aids are specialized products; many are already built into the browser and the operating system, and they're used by people with disabilities and everyone else alike:

• Reader mode in the browser: removes distractions and leaves only the main text, with adjustable typography and size. Helps dyslexia, ADHD, and low vision.
• High-contrast modes / contrast themes of the system, and dark mode: they recolor the interface to make it more legible.
• OS settings for text size, large cursor, reduce motion, or reduce transparency.

They're relevant to us because a well-built site respects these user preferences (for example, "reduce motion"), whereas a poorly built one ignores them or even breaks with them. The how of respecting them is material for Modules 4 and 5.

This is the most important conceptual idea of the lesson, and it's worth understanding even though the technical detail comes later.

When the browser loads a page, it doesn't just build the DOM (the tree of HTML elements that gets drawn on screen). In parallel, it also builds a simplified, "semantic" version meant for AT: the accessibility tree. In it, each relevant element is represented with data such as:

• its role (is it a button? a link? a heading? a text field?),
• its name (the text that identifies it: "Enroll," "Search course"),
• its state and value (is it checked? expanded? disabled? what does it contain?).

The browser exposes that tree through the operating system's accessibility APIs (there's one on Windows, another on macOS, another on Android...). The screen reader, the voice control, or the braille display don't read your pixels or your CSS: they query that tree through the API. Whatever isn't well represented there, for the AT doesn't exist or exists wrongly.

From here comes the moral that governs half the course: we program for the accessibility tree, not just for what's visible. A <div> styled to look like a button may look like a button on screen, but if it doesn't register as a button in the tree (no role, no name), the screen reader will announce "nothing" and voice control won't find it. How to fill that tree well -with semantic HTML and, when needed, ARIA- is exactly the content of Modules 4 and 5. Here you only need the mental picture: there's an intermediate tree, and AT depends on it.

We close by joining the module's two lessons. This table connects the disability groups (02-01) with the AT most common in each case. It's not a rigid mapping (each person combines whatever works for them), but it gives a sense of direction:

Notice a revealing pattern: for several groups (deafness, color blindness, cognitive) the "assistive technology" is, at bottom, that the site is well built. There's no gadget that fixes bad design: accessibility is built at the source.

• Believing that "accessible" = "works with a screen reader." The screen reader is just one AT. There are voice users, switch users, zoom users, caption users... and many who only need good design. Designing solely for the reader leaves the rest out.
• Assuming a single screen reader. NVDA, JAWS, VoiceOver, and TalkBack don't behave the same. We'll see this when we talk about testing (Module 6).
• Forgetting that almost all motor AT emulates the keyboard. If something doesn't work with the keyboard, it doesn't work with a switch, or with voice "by numbers," or with many alternative keyboards. The keyboard is the lowest common denominator.
• Thinking AT "guesses." It doesn't: it reads the accessibility tree. If the markup is poor, the AT can't make up for it.
• Tip: install NVDA (Windows) or turn on VoiceOver (Mac) and spend ten minutes "listening to" a website. Don't try to fix anything yet; just understand the experience. It's the best empathy investment of the course.

Exercise 1. Match each Cursalia user with the AT they probably use and why:

1. Marta, blind, wants to read the discount code for her enrollment precisely.
2. A student with ALS who only controls their gaze.
3. Lucía, with a spinal injury, who also has fatigue and prefers not to type much.

Exercise 2. Explain in your own words, in 3-4 sentences, what the accessibility tree is and why a <div> that looks like a button can be a problem for a screen reader and for voice control.

Exercise 3. State True or False and justify:

1. "If my site works with the keyboard, it will also work for most switch and alternative-keyboard users."
2. "A deaf person needs to install a special assistive technology to watch Cursalia's videos."
3. "NVDA is paid and only runs on macOS."

Solution 1.

1. Marta: screen reader + braille display. Voice can make an alphanumeric code ambiguous; braille lets her read it character by character with precision.
2. Eye tracking, possibly with dwell or a switch to "click." They retain control of their eyes even if not of their hands.
3. Voice control (giving commands and dictating), perhaps combined with keyboard navigation when convenient. It reduces the physical effort of typing.

Solution 2. The accessibility tree is the semantic representation (role, name, state, and value of each element) that the browser builds in parallel to the DOM and exposes to AT through the system's accessibility APIs. AT reads that tree, not the pixels. A <div> that looks like a button looks like a button on screen, but in the tree it doesn't register as a button: it has no button role and no accessible name. That's why the screen reader doesn't announce it as something activatable and voice control finds no word ("click...") with which to activate it.

Solution 3.

1. True. Most motor-access devices (scanning switches, alternative keyboards) move through the same focusable elements in the same order as the keyboard: if the keyboard works, they do too.
2. False. They don't need any special AT: they need the site to offer captions and a transcript. The help, in this case, is in the content, not in a gadget.
3. False. NVDA is free and open source, and it runs on Windows (VoiceOver is the macOS one).

We now have the toolkit: screen readers (NVDA, JAWS, VoiceOver, TalkBack), magnifiers and zoom, braille displays, voice control, switches, eye tracking, alternative keyboards, and the system's reading/contrast modes. And, above all, we have the concept that ties them together: AT doesn't read your visual design but the accessibility tree that the browser exposes through the accessibility APIs. We program for that tree -whose practical construction arrives in Modules 4 and 5.

We're still missing the piece that turns all of this into design decisions: how people actually navigate with these tools. How does Marta go through the catalog with NVDA? How does Lucía tab through the enrollment form? What exactly happens when something is poorly built? That's the next lesson, 02-03: How People with Disabilities Use the Web, where we'll see the real usage patterns and the exact points where the experience breaks.