Ja sabem qui són (02-01) i amb quines eines naveguen (02-02). Falta la peça que converteix tot això en decisions de disseny: com es navega realment amb aquestes tecnologies d'assistència, i per què això condiciona com hem de construir cada pàgina. Aquesta és la lliçó que "tanca el cercle" del mòdul: aquí veuràs que les TA no consumeixen la web com tu, sinó seguint patrons molt concrets —per teclat, per estructura, per veu, amb zoom— i que si el lloc ignora aquests patrons, l'experiència es trenca en punts identificables.

Recorrerem quatre patrons d'ús, i després narrarem tres escenaris complets a Cursalia (la Marta amb NVDA, la Lucía només amb teclat, i una alumna amb zoom al 300%) mostrant on i per què falla quan el lloc no està ben fet. Farem servir algun fragment HTML mínim per il·lustrar una bona davant d'una mala estructura, però sense entrar en la implementació completa (la semàntica i ARIA es veuen al mòdul 4). L'objectiu aquí és motivar el perquè; el com arriba als mòduls següents.

Contingut

  1. Patró 1: navegació per teclat
  2. Patró 2: ús de lector de pantalla per estructura
  3. Patró 3: navegació per veu
  4. Patró 4: zoom, ampliació i reflow
  5. Escenari A — la Marta busca un curs amb NVDA
  6. Escenari B — la Lucía es matricula només amb teclat
  7. Escenari C — la Sofía estudia amb zoom al 300%
  8. Què tenen en comú tots els errors

  1. Patró 1: navegació per teclat

Moltíssimes persones no fan servir el ratolí: usuaris motrius, de lector de pantalla, de commutador, de veu… i també usuaris avançats. Tots comparteixen un mateix llenguatge, el del teclat. Les seves tecles bàsiques:

Tecla Què fa
Tab Avança al següent element interactiu (enllaç, botó, camp).
Shift + Tab Retrocedeix a l'anterior.
Enter Activa enllaços i botons; envia formularis.
Espai Activa botons; marca caselles; desplaça la pàgina.
Fletxes Es mouen dins d'un component: opcions d'un radio, un desplegable, un menú, unes pestanyes.
Esc Tanca menús, diàlegs i finestres emergents.

D'aquest patró neixen tres exigències que repetirem tot el curs:

  • Tot allò operable amb ratolí ha de ser-ho amb teclat. Si un menú només s'obre "en passar-hi per sobre" o un botó només respon al clic, qui fa servir el teclat queda fora.
  • El focus s'ha de veure. La persona necessita saber on és el "cursor de teclat". Aquest requadre o ressalt és el focus visible. Si el disseny l'elimina (un CSS que treu l'outline), l'usuari navega a cegues.
  • L'ordre de focus ha de ser lògic. Tab hauria de recórrer la pàgina en un ordre que tingui sentit (normalment, el de lectura). Si salta de l'encapçalament al peu i després al menú, recórrer la pàgina es torna un laberint.

  1. Patró 2: ús de lector de pantalla per estructura

Aquí està la revelació que més canvia la mentalitat d'un desenvolupador: una persona cega no llegeix la pàgina de dalt a baix paraula per paraula. Seria lentíssim. En comptes d'això, navega per l'estructura, fent servir el marcatge com un índex. Les seves dreceres habituals:

  • Saltar per encapçalaments (a NVDA/JAWS, la tecla H): recorre els <h1>, <h2>, <h3>… com qui fulleja els titulars d'un diari per orientar-se.
  • Llista d'enllaços: demana "dona'm tots els enllaços" i tria. Per això quaranta enllaços anomenats "Veure més" són inútils: fora de context, no diuen on van.
  • Regions / landmarks: salta directament a zones com "navegació principal", "contingut principal", "peu", si el lloc les declara.
  • Mode navegació vs. mode focus. Aquest matís és clau. En llegir, el lector està en mode navegació (o "d'exploració"): les tecles com H o les fletxes serveixen per moure's pel contingut. Però en arribar a un camp de formulari, el lector entra en mode focus (o "de formularis"): ara les tecles escriuen al camp en comptes de navegar. Molts lectors canvien entre tots dos modes automàticament en entrar i sortir dels camps.

La conseqüència de disseny és enorme: l'estructura semàntica és la interfície per a l'usuari de lector de pantalla. Compara aquests dos catàlegs de Cursalia:

<!-- MALAMENT: tot són <div>. Sense encapçalaments, sense estructura. -->
<div class="titol">Catàleg de cursos</div>
<div class="card">
  <div class="nom">Python des de zero</div>
  <div class="link" onclick="anar()">Veure més</div>
</div>
<!-- BÉ: encapçalaments reals i enllaços amb text significatiu. -->
<h1>Catàleg de cursos</h1>
<article>
  <h2>Python des de zero</h2>
  <a href="/cursos/python">Veure el curs «Python des de zero»</a>
</article>

En el primer cas, l'usuari prem H per saltar per encapçalaments i no passa res: no hi ha encapçalaments; el lloc és un mur pla. Demana la llista d'enllaços i sent "Veure més", sense destinació. En el segon, salta de <h2> en <h2> sentint els noms dels cursos i cada enllaç s'anuncia amb la seva destinació. Mateix aspecte visual; experiència oposada. (El detall de per què <h2> i <article> són els correctes, i com etiquetar-los, és el mòdul 4; aquí només observem l'efecte.)

  1. Patró 3: navegació per veu

Qui fa servir control per veu maneja la pàgina parlant. Les seves ordres més típiques:

  • Activar per nom: "fes clic a Matricular-me", "prem Cerca". El sistema busca un element el nom accessible del qual coincideixi amb el que s'ha dit.
  • Mostrar números / graella: quan un element no té nom pronunciable (una icona "🔍" sense etiqueta), la persona diu "mostrar números" i el sistema superposa un número a cada element clicable; llavors diu "clic al 7". És el pla B, més lent i maldestre.
  • Dictat i desplaçament: "desplaça't cap avall", "torna amunt", dictar text en un camp.

La lliçó de disseny: el nom visible hauria de coincidir amb el nom accessible. Si el botó diu "Matricular-me" en pantalla però internament s'anomena una altra cosa (o res), l'ordre "fes clic a Matricular-me" falla, i la persona ni tan sols sap per què. Les icones sense etiqueta obliguen a recórrer als números, encarint cada acció. (Com garantir aquest nom accessible: mòduls 4 i 5.)

  1. Patró 4: zoom, ampliació i reflow

La persona amb baixa visió amplia. No parlem d'un cas rar: ampliacions del 200% són quotidianes, i amb magnificadors s'arriba al 300-400%. En ampliar tant, en una pantalla hi caben molt poques paraules, així que el comportament correcte és el reflow: el contingut es reorganitza en una sola columna que es llegeix baixant en vertical, sense scroll horitzontal.

On es trenca:

  • Scroll horitzontal: si en ampliar apareix una barra horitzontal, la persona ha d'arrossegar a esquerra i dreta a cada línia per llegir. És esgotador i fa que es perdin trossos.
  • Contingut que se solapa o es talla: menús que tapen el text, botons que se surten de la pantalla, text retallat.
  • Barres fixes que es mengen la pantalla: una capçalera fixa que al 300% ocupa mitja pantalla i deixa el contingut en una escletxa.

El principi: el disseny ha de ser flexible/responsive perquè el mateix contingut hi càpiga reorganitzat. És la mateixa qualitat que fa que un lloc funcioni bé al mòbil; no és casualitat. (Els criteris exactes de redimensionament i reflow són del mòdul 4.)

  1. Escenari A — la Marta busca un curs amb NVDA

La Marta és cega i fa servir NVDA a Windows. Vol trobar el curs "Python des de zero" al catàleg de Cursalia i obrir-ne la fitxa.

Com ho intenta (el seu patró natural): en carregar el catàleg, la Marta prem H per saltar per encapçalaments i fer-se un mapa ràpid de la pàgina. Després demanaria la llista d'enllaços per anar directa al curs.

Lloc mal fet:

  1. Prem H… i NVDA diu "sense encapçalaments". Tota la pàgina és un mar de <div>. La Marta ha perdut el seu mapa: ara ha de sentir la pàgina sencera, linealment.
  2. Demana la llista d'enllaços i sent "Veure més, Veure més, Veure més…" quaranta vegades, tots idèntics. No hi ha manera de saber quin és Python.
  3. Les targetes duen una imatge del curs sense text alternatiu: NVDA llegeix "imatge" o el nom de l'arxiu, curso_0423.jpg. Inútil.
  4. La Marta abandona i se'n va a una altra plataforma. La barrera no va ser la seva ceguesa; va ser la manca d'estructura i de text alternatiu.

Lloc ben fet:

  1. Prem H i sent "Catàleg de cursos, encapçalament 1", "Python des de zero, encapçalament 2", "Disseny UX, encapçalament 2"… En segons té l'índex mental.
  2. Es planta a "Python des de zero" i el seu enllaç s'anuncia com "Veure el curs Python des de zero, enllaç". Prem Enter i entra.
  3. Total: uns segons, amb autonomia i sense frustració.

  1. Escenari B — la Lucía es matricula només amb teclat

La Lucía té una lesió medul·lar i navega només amb teclat (sense ratolí). Recuperem l'escena que vam deixar oberta a 02-01: vol completar el formulari de matrícula.

Com ho intenta: Tab per avançar camp a camp, escriure, fletxes per triar opcions, Enter per enviar.

Lloc mal fet — es trenca en tres punts:

  1. Focus invisible. Algú va "netejar" el disseny traient l'outline del CSS. La Lucía prem Tab diverses vegades i no veu on és: teclegen a cegues, sense saber en quin camp escriu.
  2. Trampa de teclat + desplegable de només-ratolí. El selector de "forma de pagament" és un <div> personalitzat que només s'obre amb clic. Amb teclat no desplega, i pitjor: en tabular, el focus queda atrapat dins seu i no en surt (una keyboard trap). La Lucía no pot ni triar pagament ni continuar.
  3. Botó final inassolible. Fins i tot esquivant l'anterior, el botó "Confirmar matrícula" és un <div onclick> que no rep focus amb Tab. La Lucía arriba a l'últim pas i no el pot prémer. Matrícula perduda.
<!-- MALAMENT: no rep focus de teclat ni s'anuncia com a botó -->
<div class="btn" onclick="confirmar()">Confirmar matrícula</div>

<!-- BÉ: un botó real és enfocable i activable amb Enter/Espai per defecte -->
<button type="submit">Confirmar matrícula</button>

Lloc ben fet: cada camp rep focus en ordre lògic, el focus es veu amb claredat, el selector de pagament s'obre i es recorre amb teclat (fletxes + Enter), i "Confirmar" és un <button> real que la Lucía activa amb Enter. Es matricula sola, sense ajuda. (El com construir aquest selector accessible és el mòdul 5; el botó semàntic, el mòdul 4.)

  1. Escenari C — la Sofía estudia amb zoom al 300%

La Sofía té baixa visió i navega amb el zoom del navegador al 300%. És a la fitxa de curs llegint el temari abans de matricular-se.

Lloc mal fet:

  1. Al 300%, la fitxa manté la seva graella de tres columnes comprimida: apareix scroll horitzontal. La Sofía ha d'arrossegar a dreta i esquerra a cada línia del temari. Al cap de dos minuts, esgotada, ho deixa.
  2. La capçalera fixa ocupa ara gairebé mitja pantalla; el contingut real s'entreveu per una escletxa.
  3. Un avís de "places limitades" queda tallat per la vora: la Sofía no arriba a llegir-lo sencer.

Lloc ben fet: en ampliar, el contingut fa reflow a una sola columna; la Sofía llegeix baixant en vertical, sense desplaçament horitzontal, la capçalera es compacta i res no se solapa. Mateixa informació, esforç mínim.

  1. Què tenen en comú tots els errors

Si observes els tres escenaris, els errors no són a l'atzar: es repeteixen i s'agrupen. I aquesta agrupació és, precisament, l'avantsala del Mòdul 3.

flowchart TD
    A["Imatges sense alternativa<br/>Vídeo sense subtítols"] --> P["No ho poden PERCEBRE"]
    B["No funciona amb teclat<br/>Focus invisible · Trampa de focus"] --> O["No ho poden OPERAR"]
    C["Text confús · Errors críptics<br/>Passos impredictibles"] --> U["No ho COMPRENEN"]
    D["div's en comptes de botons<br/>Nom accessible absent"] --> R["No és ROBUST per a les TA"]
  • Que la Marta no percebi les imatges ni pugui llegir el catàleg → és un error de Percepció.
  • Que la Lucía no pugui tabular, no vegi el focus o quedi atrapada → és un error d'Operabilitat.
  • Que en Hugo (02-01) no entengui les preguntes o els errors → és un error de Comprensió.
  • Que un <div onclick> no consti com a botó a l'arbre d'accessibilitat → és un error de Robustesa.

Perceptible, Operable, Comprensible, Robust. Aquests quatre calaixos no són una casualitat: són els quatre principis POUR de WCAG que vam presentar a la lliçó 01-04. Acabem de descobrir, des de l'experiència real de les persones, per què l'estàndard està organitzat exactament així.

Errors Comuns i Consells

  • Creure que la gent llegeix la web com tu. L'usuari de lector de pantalla salta per estructura; el de teclat tabula; el de baixa visió amplia. Dissenyar suposant un recorregut lineal amb ratolí els deixa a tots fora.
  • Treure el focus visible "perquè afea". És un dels danys més freqüents i més greus: deixa la Lucía navegant a cegues. Mai no eliminis l'indicador de focus sense substituir-lo per un de millor.
  • Fabricar botons i controls amb <div>. Semblen funcionar amb ratolí, però no reben focus, no responen a Enter/Espai i no consten a l'arbre d'accessibilitat. És l'arrel de mig mòdul 2.
  • Enllaços i botons sense text significatiu. "Veure més", "Aquí", icones sense nom: fora de context no diuen res al lector de pantalla ni al control per veu.
  • Provar només amb ratolí i vista. Consell: navega una tasca completa de Cursalia fent servir només Tab, Enter i fletxes, sense tocar el ratolí. En cinc minuts trobaràs barreres que a simple vista no es veuen.

Exercicis

Exercici 1. Un desenvolupador de Cursalia diu: "He provat el catàleg amb el ratolí i funciona genial, així que és accessible". Dona tres raons, basades en els patrons d'aquesta lliçó, per les quals aquesta prova és insuficient.

Exercici 2. A l'escenari de la Lucía vam identificar tres punts de trencament (focus invisible, trampa de teclat, botó no enfocable). Classifica cadascun segons el principi POUR al qual correspon i explica en una frase per què.

Exercici 3. La Sofía amplia al 300% i apareix scroll horitzontal. (a) Quin patró d'ús està fallant? (b) Quin comportament hauria de tenir la pàgina en el seu lloc? (c) A quin principi POUR pertany aquest problema?

Solucions

Solució 1. Exemples: (1) No va provar amb teclat: un usuari que només tabula podria no assolir targetes o botons que amb ratolí sí que funcionen. (2) No va provar amb lector de pantalla: sense encapçalaments ni textos d'enllaç significatius, la Marta no pot navegar per estructura encara que "amb el ratolí es vegi bé". (3) No va provar amb veu ni amb zoom: icones sense nom trenquen el control per veu, i l'ampliació al 200-300% podria provocar scroll horitzontal. En resum, "funciona amb ratolí i vista" només cobreix un dels molts patrons d'ús.

Solució 2.

  • Focus invisible → Operable. L'usuari de teclat no pot operar la interfície amb seguretat si no sap on és el focus.
  • Trampa de teclat → Operable. Si el focus queda atrapat, la persona no pot continuar l'operació; és un bloqueig total de l'operabilitat.
  • Botó no enfocable (<div onclick>) → Robust (i Operable). No consta com a botó a l'arbre d'accessibilitat (robustesa davant les TA) i, a més, no es pot activar amb teclat (operabilitat).

Solució 3. (a) Falla el patró de zoom/ampliació i reflow. (b) La pàgina hauria de reorganitzar el contingut en una sola columna (reflow) per poder llegir-lo baixant en vertical, sense scroll horitzontal. (c) Pertany al principi Perceptible (que l'usuari pugui percebre el contingut en ampliar-lo, sense que es perdi o quedi inaccessible).

Conclusió

Hem vist com es fa servir realment la web amb tecnologies d'assistència: per teclat (amb focus visible i ordre lògic), per estructura amb el lector de pantalla (saltant per encapçalaments, enllaços i regions, alternant mode navegació i mode focus), per veu (activant elements pel seu nom) i amb zoom (esperant reflow sense scroll horitzontal). I a Cursalia hem comprovat, amb la Marta, la Lucía i la Sofía, on i per què es trenca l'experiència quan el lloc ignora aquests patrons.

Amb això tanquem el Mòdul 2. Ara entenem les persones, les seves eines i les seves formes de navegar. I hem fet un descobriment que ho connecta tot: els errors no són aleatoris: s'agrupen en quatre famílies —no ho perceben, no ho operen, no ho comprenen, no és robust—. Aquestes quatre famílies són els principis POUR de WCAG. No són una abstracció acadèmica: són la resposta sistemàtica a les barreres reals que acabem de presenciar.

Això és exactament el que obre el Mòdul 3: Principis del Disseny Accessible, on desenvoluparem en profunditat Perceptible, Operable, Comprensible i Robust. Ja no els veurem com una llista teòrica, sinó com la solució ordenada als problemes de la Marta, la Lucía, la Sofía, en Diego i en Hugo. Entendre les persones era el requisit previ; a partir d'ara, comencem a dissenyar la resposta.

© Copyright 2026. Tots els drets reservats