Amb els tres principis anteriors hem cobert allò que la persona percep, opera i comprèn. Però tot això descansa sobre una condició tècnica: que el contingut estigui construït de manera que navegadors i tecnologies d'assistència l'interpretin de manera fiable, avui i en el futur. Aquest és el quart i últim principi POUR, Robust. És el més curt en criteris i el més "de lampisteria", però el més crític: si el codi no és robust, un component pot ser perfecte visualment i tot i així no existir per a la Marta i el seu NVDA. Aquí connectem directament amb l'arbre d'accessibilitat que vam veure al Mòdul 2.

1. Què significa "robust"
2. Pauta 4.1: Compatible
3. El vincle amb l'arbre d'accessibilitat
4. Taula resum de criteris
5. Errors comuns i consells
6. Exercicis
7. Conclusió i tancament del mòdul

Robust vol dir que el contingut ha de poder ser interpretat de manera fiable per una àmplia varietat d'agents d'usuari, incloses les tecnologies d'assistència presents i futures. No n'hi ha prou que "es vegi bé al meu navegador": el marcatge ha d'exposar informació que qualsevol TA pugui llegir, ara i quan apareguin noves versions de lectors, navegadors o dispositius. La robustesa és allò que fa que la teva feina en accessibilitat sobrevisqui al temps.

Maximitzar la compatibilitat amb els agents d'usuari actuals i futurs.

Històricament, 4.1.1 exigia marcatge ben format (sense id duplicats, etiquetes correctament imbricades i tancades). A WCAG 2.2 aquest criteri es va marcar com a obsolet i es va eliminar. Per què? Perquè els navegadors moderns i les TA ja recuperen de manera robusta i consistent els errors de marcatge que aquest criteri pretenia evitar: l'especificació HTML defineix com parsejar codi imperfecte, així que aquestes errades ja no trenquen l'accessibilitat per si mateixes. Els problemes que sí que importen (per exemple un id duplicat que trenca una associació aria-labelledby) queden coberts per altres criteris com 4.1.2 o 1.3.1. Conclusió pràctica: no persegueixis la validesa del marcatge com un fi en si mateix; persegueix que nom, funció i valor arribin correctes.

És el criteri central de la robustesa. Per a tot component d'interfície —especialment els personalitzats— la TA ha de poder determinar:

• Nom (name): com es diu ("Filtrar per categoria").
• Funció (role): què és (un botó, un desplegable, una casella).
• Valor/estat (value/state): en quina situació està (obert/tancat, seleccionat, expandit).

Amb HTML natiu això ve de franc: un <button> o un <select> ja exposen el seu nom, funció i estat. El problema apareix amb components fets a mà amb <div> i JavaScript: sense role, sense nom accessible i sense estats ARIA, són closques buides per a la TA.

Els missatges d'estat —confirmacions, errors, resultats, progrés— s'han de poder anunciar a la TA sense moure el focus. Quan Cursalia mostra "S'han trobat 12 cursos" després de filtrar, o "Matrícula desada", la Marta ho ha de sentir encara que el seu focus segueixi al filtre. Tècnicament això s'aconsegueix amb regions "en viu" (per exemple aria-live), però aquí n'hi ha prou amb retenir el requisit.

Al Mòdul 2 vam veure que la TA no llegeix el DOM visual, sinó l'arbre d'accessibilitat: una representació que el navegador construeix exposant el nom, la funció i l'estat de cada element. El principi Robust és, literalment, l'exigència que aquest arbre estigui ben poblat.

Imagina el desplegable del filtre de Cursalia construït amb <div> sense semàntica. Visualment funciona: s'obre, es tanca, ressalta l'opció triada. Però a l'arbre d'accessibilitat no hi ha cap "botó", cap nom, cap estat "expandit". La Marta tabula i NVDA anuncia... res útil, o un simple "clic". El control és invisible per a ella. La solució conceptual és donar name/role/value correctes: fer servir HTML natiu sempre que es pugui, i quan no, aplicar ARIA per declarar funció i estat.

L'HTML semàntic i ARIA que implementen name/role/value són el Mòdul 4: HTML Semàntic i ARIA. El comportament robust en contingut dinàmic i SPAs (anunciar canvis, gestionar el focus en navegar entre vistes) s'aprofundeix al Mòdul 7.

• Reinventar controls amb <div> i <span>. Un <div onclick> no és un botó per a la TA. Comença sempre per l'element natiu (<button>, <select>, <input>), que porta name/role/value de fàbrica.
• Creure que 4.1.1 encara exigeix "HTML vàlid". A WCAG 2.2 està obsolet; el que importa és que name/role/value arribin bé. Tot i així, evita id duplicats perquè trenquen associacions ARIA (això ho penalitzen 4.1.2 i 1.3.1).
• Posar ARIA sense gestionar l'estat. Declarar role="button" però no actualitzar aria-expanded deixa el valor mentint. La regla d'or: cap ARIA és millor que ARIA incorrecte.
• Mostrar missatges que només es veuen. Un "Desat" que apareix visualment però no s'anuncia incompleix 4.1.3; la Marta no s'assabenta que la seva acció ha funcionat.
• Consell: davant de qualsevol component, fes-te tres preguntes —té nom?, se sap què és?, se sap el seu estat?—. Si alguna falla, no és robust.

Exercici 1. El desplegable del filtre de Cursalia està fet amb <div> i JavaScript; visualment obre i tanca un panell d'opcions. Amb NVDA, la Marta no percep que és un control ni si està obert. Quin criteri s'incompleix i quines tres informacions ha d'exposar el component?

Exercici 2. Després d'aplicar el filtre, apareix el text "12 cursos trobats", però la Marta, el focus de la qual segueix al control, no sent res. Quin criteri s'hi aplica, de quin nivell és i què exigeix?

Exercici 3. Un company proposa auditar el lloc validant l'HTML amb el validador del W3C per "complir 4.1.1". Què li explicaries sobre l'estat d'aquest criteri a WCAG 2.2 i cap a on reorientar l'esforç?

Solució 1. S'incompleix 4.1.2 Nom, funció, valor (A). El component ha d'exposar: nom (p. ex. "Filtrar per categoria"), funció/rol (que és un control desplegable/botó que obre una llista) i valor/estat (si està expandit o contret, i quina opció està seleccionada). La implementació amb HTML natiu o ARIA es veu al Mòdul 4.

Solució 2. S'hi aplica 4.1.3 Missatges d'estat (AA). Exigeix que el missatge d'estat s'anunciï a la TA sense moure el focus, típicament mitjançant una regió en viu, perquè la Marta l'escolti mentre segueix treballant al filtre.

Solució 3. Li explicaria que 4.1.1 (parsing) està obsolet i es va eliminar a WCAG 2.2: els navegadors ja recuperen de manera fiable el marcatge imperfecte, així que validar HTML no és el que garanteix accessibilitat. L'esforç s'ha de reorientar cap a 4.1.2 (que name/role/value siguin correctes a cada component) i cap a 4.1.3 (missatges d'estat). La validesa segueix sent bona higiene —sobretot evitar id duplicats—, però no és un criteri en si mateix.

El principi Robust és la garantia tècnica de tot l'anterior: sense name/role/value correctes i sense missatges d'estat anunciables, els altres tres principis es queden a la superfície visual i no arriben a l'arbre d'accessibilitat que fa servir la Marta. Amb això tanquem el Mòdul 3: hem recorregut els quatre principis POUR entenent què exigeix cadascun i els seus criteris clau de WCAG 2.2, amb els seus nivells A/AA.

Fins aquí hem parlat de requisits. A partir del Mòdul 4 canviem de pla: passem de "què exigeix WCAG" a "com s'implementa en HTML i CSS". Començarem pel HTML semàntic —la manera més directa i robusta de donar name/role/value de franc— i seguirem amb formularis accessibles, ARIA i contrast. Tot allò que en aquest mòdul hem remès amb un "s'implementa al mòdul 4/5" comença a construir-se ara, amb codi real.