A la lliçó anterior vam conèixer les persones i les seves barreres. Ara coneixem les seves eines. La Marta (cega), la Lucía (només teclat), en Diego (sord) i la resta no accedeixen a la web a mà descoberta: es recolzen en programes i dispositius que tradueixen el contingut a un canal que sí que poden fer servir —veu, braille, ampliació, ordres parlades, un sol botó—. Aquestes eines són les tecnologies d'assistència (TA, o AT en anglès).

En aquesta lliçó farem una panoràmica de les principals: lectors de pantalla, magnificadors i zoom, línies braille, control per veu, accés per commutador, seguiment ocular, teclats alternatius i els modes de lectura/alt contrast del navegador i del sistema. A més introduirem, a nivell conceptual, com una TA es recolza en el marcatge per funcionar: aquí apareix la idea de l'arbre d'accessibilitat i les API d'accessibilitat.

Abast: descrivim què és cada TA i per a qui, no com es programa per a elles (això és semàntica, ARIA, alt… mòduls 4 i 5), ni els patrons de navegació detallats (com se salta per encapçalaments, com es fa servir el mode focus… això és la lliçó 02-03). Aquí muntem el catàleg d'eines; el seu maneig fi ve després.

1. Què són les tecnologies d'assistència
2. Lectors de pantalla
3. Magnificadors, zoom i ampliació
4. Línies braille
5. Control per veu
6. Accés per commutador (switch)
7. Seguiment ocular (eye tracking)
8. Teclats alternatius i altres dispositius d'entrada
9. Modes de lectura i alt contrast del navegador/SO
10. Com "veuen" les TA la teva web: l'arbre d'accessibilitat
11. Mapa: discapacitat → TA típica

Una tecnologia d'assistència és qualsevol producte —programari o maquinari— que permet a una persona amb discapacitat dur a terme una tasca que d'una altra manera li resultaria difícil o impossible. A la web, la seva missió és fer de mitjancera entre la pàgina i la persona: reben el contingut, el transformen (a veu, a text gran, a braille) i, en sentit invers, tradueixen les accions de la persona (una ordre de veu, la pulsació d'un commutador) en interaccions amb la pàgina.

Dues idees que convé fixar des d'ara:

• La TA no endevina. Funciona bé només si el lloc li ofereix informació correcta i estructurada. Un lector de pantalla no "entén" una imatge: llegeix la descripció que el desenvolupador li hagi donat. Aquesta dependència és la raó de ser de tot el curs.
• Una mateixa persona pot combinar diverses TA (per exemple, lector de pantalla + línia braille) i, a més, ajustos del sistema operatiu (mida de font, reduir moviment). No hi ha "un usuari de TA" estàndard.

Són la TA més coneguda. Un lector de pantalla (screen reader) converteix el contingut de la pantalla en veu sintetitzada i/o braille. El fan servir sobretot persones cegues i algunes amb baixa visió severa o dificultats de lectura. La persona no veu la pàgina: l'escolta, element a element, i la recorre amb el teclat o amb gestos tàctils.

Els principals, amb la seva plataforma habitual:

Una conseqüència pràctica d'aquesta taula: hi ha molts lectors i cap no és idèntic a un altre. El que sona perfecte a NVDA es pot llegir diferent a VoiceOver. Per això, més endavant (mòdul 6), provar amb més d'un lector serà part del procés de proves. De moment, queda't amb que existeixen, en quina plataforma viuen i que són gratuïts de provar en gairebé tots els sistemes.

No totes les persones amb discapacitat visual són cegues. Moltes tenen baixa visió i fan servir la seva resta visual ampliada. Aquí hi ha una escala de solucions:

• Zoom del navegador. El més simple i universal: amb Ctrl + + (o Cmd + +) s'engrandeix tot. Moltíssima gent el fa servir a diari, amb o sense discapacitat. Ampliacions del 200% són habituals; WCAG exigeix que la pàgina segueixi funcionant a aquest nivell.
• Magnificadors del sistema operatiu (Lupa de Windows, Zoom de macOS): amplien una porció de la pantalla, de vegades amb una lent que segueix el cursor, fins al 400% o més.
• Programari especialitzat com ZoomText o MAGic, que a més d'ampliar milloren el contrast, suavitzen les vores i poden combinar l'ampliació amb la lectura per veu.

La barrera clàssica que pateix aquest grup: quan la pàgina s'amplia i apareix scroll horitzontal o el contingut es descol·loca i se solapa. El comportament correcte (que el contingut es reorganitzi en una columna, el reflow) el veurem com a patró d'ús a 02-03 i com a criteri tècnic al mòdul 4.

Una línia (o pantalla) braille és un dispositiu maquinari que es connecta a l'ordinador o al mòbil i representa el text en braille tàctil mitjançant una fila de cel·les amb punts que pugen i baixen. Treballa juntament amb un lector de pantalla: el lector decideix quin text mostrar i la línia braille el materialitza sota els dits.

Per què braille i no només veu? Perquè:

• És imprescindible per a persones sordcegues, que no poden fer servir la sortida de veu.
• Permet llegir amb precisió ortografia, codi, xifres o noms propis que la veu pot tornar ambigus.
• Moltes persones cegues prefereixen el braille per a la lectura atenta (estudiar, revisar) davant del consum ràpid per veu.

Per a nosaltres la implicació és directa: tot el que el lector de pantalla llegeix, la línia braille ho transmet. Si una imatge no té text alternatiu, no hi ha ni veu ni braille. És a dir, millorar per al lector de pantalla millora també per al braille "de franc".

El control per veu permet manejar el dispositiu parlant: dictar text i, sobretot, donar ordres ("obre el menú", "fes clic a Matricular-me", "desplaça't cap avall"). El fan servir persones amb discapacitat motriu que no poden fer servir teclat ni ratolí, i també persones amb dislèxia o fatiga que prefereixen dictar.

Exemples habituals: Dragon (Dragon NaturallySpeaking / Dragon Professional) a Windows, Voice Control a macOS/iOS i Voice Access a Android.

Un matís important que desenvoluparem a 02-03: el control per veu sol recolzar-se en el nom visible o accessible dels elements. Si un botó s'anomena de debò "Matricular-me", la persona diu "fes clic a Matricular-me" i funciona. Si el botó és una icona sense nom, no hi ha cap paraula per pronunciar, i molts sistemes recorren llavors a "mostrar números" (superposar un número a cada element clicable) com a pla B.

L'accés per commutador és per a persones amb mobilitat molt reduïda que només poden fer un gest fiable: prémer un o dos botons (un switch), accionat amb la mà, el cap, el peu o fins i tot un buf. Amb tan poca entrada, com es navega per tota una web?

Mitjançant escombrat (scanning): el sistema ressalta els elements un a un de manera automàtica, i la persona acciona el commutador quan el ressaltat arriba a l'element que vol. És com una navegació per teclat portada a l'extrem: en el fons, recorre els mateixos elements enfocables en el mateix ordre.

La conseqüència per al disseny és contundent: si una cosa no és assolible amb teclat o l'ordre de focus és un caos, per a un usuari de commutador no és "incòmode", és literalment inassolible, i cada element de més en el recorregut és temps i esforç. Per això el treball que fem pel teclat (mòdul 5) beneficia directament aquest grup.

El seguiment ocular rastreja cap a on mira la persona amb una càmera especial i mou el punter a aquell punt; la "pulsació" es fa fixant la mirada un instant (dwell) o amb un commutador auxiliar. El fan servir persones amb mobilitat molt limitada (per exemple, ELA o tetraplegia) que conserven el control dels ulls.

El seu gran enemic són els objectius petits i junts: apuntar amb la mirada és menys precís que amb el ratolí, així que botons diminuts o enllaços enganxats es tornen molt difícils d'encertar. Enllaça amb la barrera d'"objectius tàctils" que ja vam veure i amb el criteri de mida d'objectiu que tractarem més endavant.

No tothom fa servir el teclat i el ratolí estàndard. Existeix un ecosistema de maquinari adaptat:

• Teclats grans, amb tecles separades o amb guia (per a tremolor o baixa precisió).
• Teclats en pantalla (virtuals), que s'accionen amb ratolí, mirada o commutador.
• Trackballs, joysticks i ratolins adaptats per a qui no maneja un ratolí normal.
• Punters de cap/boca per escriure tecla a tecla.

El punt clau: gairebé tots aquests dispositius, per sota, emulen un teclat. És a dir, generen pulsacions de tecla, Tab, Enter, fletxes… Per això una idea que repetirem en tot el curs: si el teu lloc funciona perfectament amb teclat, funciona amb la immensa majoria d'aquests dispositius. El teclat és el "mínim comú denominador" de l'accessibilitat motriu.

No totes les ajudes són productes especialitzats; moltes ja estan integrades al navegador i al sistema operatiu, i les fan servir tant persones amb discapacitat com qualsevol:

• Mode lectura del navegador: elimina distraccions i deixa només el text principal, amb tipografia i mida ajustables. Ajuda la dislèxia, el TDAH i la baixa visió.
• Modes d'alt contrast / temes de contrast del sistema, i el mode fosc: recoloregen la interfície per fer-la més llegible.
• Ajustos del SO de mida de text, cursor gran, reduir moviment o reduir transparències.

Per a nosaltres són rellevants perquè un lloc ben construït respecta aquestes preferències de l'usuari (per exemple, "reduir moviment"), mentre que un de mal fet les ignora o fins i tot es trenca amb elles. El com respectar-les és matèria dels mòduls 4 i 5.

Aquesta és la idea conceptual més important de la lliçó, i convé entendre-la encara que el detall tècnic vingui després.

Quan el navegador carrega una pàgina, no només construeix el DOM (l'arbre d'elements HTML que es dibuixa en pantalla). Construeix també, en paral·lel, una versió simplificada i "semàntica" pensada per a les TA: l'arbre d'accessibilitat (accessibility tree). Aquí, cada element rellevant es representa amb dades com:

• el seu rol (és un botó? un enllaç? un encapçalament? un camp de text?),
• el seu nom (el text que l'identifica: "Matricular-me", "Cerca curs"),
• el seu estat i valor (està marcat? desplegat? deshabilitat? què conté?).

El navegador exposa aquest arbre a través de les API d'accessibilitat del sistema operatiu (n'hi ha una a Windows, una altra a macOS, una altra a Android…). El lector de pantalla, el control per veu o la línia braille no llegeixen els teus píxels ni el teu CSS: consulten aquest arbre a través de l'API. El que no estigui ben representat allà, per a la TA no existeix o existeix malament.

D'aquí surt la moralitat que governa mig curs: programem per a l'arbre d'accessibilitat, no només per al que es veu. Un <div> estilitzat com a botó pot semblar un botó en pantalla, però si a l'arbre no consta com a botó (sense rol, sense nom), el lector de pantalla anunciarà "res" i el control per veu no el trobarà. Com omplir bé aquest arbre —amb HTML semàntic i, quan calgui, ARIA— és justament el contingut dels mòduls 4 i 5. Aquí només necessites la foto mental: existeix un arbre intermedi i les TA en depenen.

Tanquem unint les dues lliçons del mòdul. Aquesta taula connecta els grups de discapacitat (02-01) amb les TA més freqüents en cada cas. No és una correspondència rígida (cada persona combina el que li serveix), però orienta:

Fixa't en un patró revelador: per a diversos grups (sordesa, daltonisme, cognitiva) la "tecnologia d'assistència" és, en el fons, que el lloc estigui ben fet. No hi ha cap aparell que arregli un mal disseny: l'accessibilitat es construeix a l'origen.

• Creure que "accessible" = "compatible amb lector de pantalla". El lector de pantalla és només una TA. Hi ha usuaris de veu, de commutador, de zoom, de subtítols… i molts que només necessiten bon disseny. Dissenyar només per al lector deixa fora la resta.
• Suposar un únic lector de pantalla. NVDA, JAWS, VoiceOver i TalkBack no es comporten igual. Ho veurem en parlar de proves (mòdul 6).
• Oblidar que gairebé tota TA motriu emula teclat. Si una cosa no va amb teclat, no va amb commutador, ni amb veu "per números", ni amb molts teclats alternatius. El teclat és el mínim comú denominador.
• Pensar que la TA "endevina". No ho fa: llegeix l'arbre d'accessibilitat. Si el marcatge és pobre, la TA no pot compensar-ho.
• Consell: instal·la NVDA (Windows) o activa VoiceOver (Mac) i dedica deu minuts a "escoltar" una web. No busquis encara arreglar res; només entendre l'experiència. És la millor inversió d'empatia del curs.

Exercici 1. Empella cada usuari de Cursalia amb la(les) TA que probablement fa servir i per què:

1. La Marta, cega, vol llegir amb precisió el codi de descompte de la seva matrícula.
2. Un alumne amb ELA que només controla la mirada.
3. La Lucía, amb lesió medul·lar, que a més té fatiga i prefereix no teclejar gaire.

Exercici 2. Explica amb les teves paraules, en 3-4 frases, què és l'arbre d'accessibilitat i per què un <div> amb aspecte de botó pot ser un problema per a un lector de pantalla i per al control per veu.

Exercici 3. Indica Vertader o Fals i justifica:

1. "Si el meu lloc funciona amb teclat, funcionarà també per a la majoria d'usuaris de commutador i de teclats alternatius."
2. "Una persona sorda necessita instal·lar una tecnologia d'assistència especial per veure els vídeos de Cursalia."
3. "NVDA és de pagament i només funciona a macOS."

Solució 1.

1. La Marta: lector de pantalla + línia braille. La veu pot tornar ambigu un codi alfanumèric; el braille li permet llegir-lo caràcter a caràcter amb precisió.
2. Seguiment ocular (eye tracking), possiblement amb dwell o un commutador per "clicar". Conserva el control dels ulls encara que no el de les mans.
3. Control per veu (donar ordres i dictar), potser combinat amb navegació per teclat quan li convingui. Redueix l'esforç físic de teclejar.

Solució 2. L'arbre d'accessibilitat és la representació semàntica (rol, nom, estat i valor de cada element) que el navegador construeix en paral·lel al DOM i exposa a les TA a través de les API d'accessibilitat del sistema. Les TA llegeixen aquest arbre, no els píxels. Un <div> amb aspecte de botó sembla un botó en pantalla, però a l'arbre no consta com a botó: no té rol de botó ni un nom accessible. Per això el lector de pantalla no l'anuncia com una cosa activable i el control per veu no troba cap paraula ("fes clic a…") amb què activar-lo.

Solució 3.

1. Vertader. La majoria de dispositius d'accés motriu (commutadors per escombrat, teclats alternatius) recorren els mateixos elements enfocables en el mateix ordre que el teclat: si el teclat funciona, ells també.
2. Fals. No necessita cap TA especial: necessita que el lloc ofereixi subtítols i transcripció. L'ajuda, en aquest cas, està en el contingut, no en un aparell.
3. Fals. NVDA és gratuït i de codi obert, i funciona a Windows (VoiceOver és el de macOS).

Ja tenim el catàleg d'eines: lectors de pantalla (NVDA, JAWS, VoiceOver, TalkBack), magnificadors i zoom, línies braille, control per veu, commutadors, seguiment ocular, teclats alternatius i els modes de lectura/contrast del sistema. I, sobretot, tenim el concepte que les uneix: les TA no llegeixen el teu disseny visual, sinó l'arbre d'accessibilitat que el navegador exposa per les API d'accessibilitat. Programem per a aquest arbre —la construcció pràctica del qual arriba als mòduls 4 i 5—.

Ens falta la peça que converteix tot això en decisions de disseny: com es navega realment amb aquestes eines. Com recorre la Marta el catàleg amb NVDA? Com tabula la Lucía pel formulari de matrícula? Què passa exactament quan una cosa està mal feta? Això és la lliçó següent, 02-03: Com les Persones amb Discapacitats Usen la Web, on veurem els patrons d'ús reals i els punts exactes on es trenca l'experiència.