Has recorregut les tres capes d'avaluació: automàtica (06-02), manual (06-01) i amb usuaris reals (06-03). El resultat és un munt de troballes heterogènies: violacions d'axe, notes de la teva llista de comprovació manual, cites de la Marta, temps de la Lucía. Ara ve la part que separa una auditoria útil d'un PDF que ningú no llegeix: interpretar aquests resultats i actuar-hi amb criteri. Un informe amb 200 troballes sense prioritat paralitza; un amb 6 troballes ben ponderades i convertides en tasques mou el producte. En aquesta lliçó aprendràs a llegir un informe, entendre severitat i impacte, prioritzar, descartar falsos positius i tancar el cercle perquè els problemes no tornin.

1. Anatomia d'una troballa
2. Severitat davant d'impacte en l'usuari
3. Prioritzar: no tot és urgent
4. VPAT / ACR: l'informe de conformitat
5. Descartar falsos positius
6. De troballa a tasca de remediació amb "criteri de fet"
7. Informe d'auditoria de Cursalia (exemple)
8. Prevenir regressions: accessibilitat a la Definition of Done

Una troballa ben documentada —vingui d'una eina o d'una sessió amb usuaris— té sempre aquests camps. Si un informe no els porta, exigeix-los: sense ells no es pot actuar.

El camp origen importa més del que sembla: una troballa que apareix a axe i en una sessió amb usuaris és inqüestionable; una que només va sortir d'una eina pot ser un fals positiu (secció 5).

Compte a confondre dues coses:

• Severitat tècnica (la que assigna l'eina): axe diu "crític/seriós/moderat/menor" segons el seu catàleg de regles. És genèrica, no coneix el teu producte.
• Impacte en l'usuari: quant de mal real causa en el teu context. Depèn de si bloqueja una tasca i de a quanta gent afecta.

Un model simple per classificar l'impacte:

La clau: una fallada que axe marca com a "moderada" pot ser blocadora en el teu producte si cau al botó de matrícula, i una "crítica" d'axe pot ser menor si és en una pàgina que ningú no visita. La severitat de l'eina és el punt de partida, no la sentència.

Prioritzar és ponderar impacte × abast. Dos eixos:

• Gravetat per a qui ho pateix: blocador, seriós o menor? (secció 2).
• Abast: en quantes pàgines apareix i amb quina freqüència es fan servir? Una fallada a la fitxa de curs i el catàleg (les pàgines més visitades de Cursalia) afecta gairebé tots els usuaris; la mateixa fallada a la pàgina "Avís legal" afecta poquíssims.

Regla pràctica: primer el blocador en pàgines molt usades; deixa per al final el menor en pàgines marginals. I si una cosa és trivial d'arreglar (5 minuts) encara que sigui menor, fes-la ja: surt gratis.

Quan una organització (o un client que comprarà Cursalia) vol saber "oficialment" com d'accessible és, es fa servir un document estàndard:

• VPAT (Voluntary Product Accessibility Template): la plantilla, publicada per l'ITI. És el format en blanc.
• ACR (Accessibility Conformance Report): el VPAT ja emplenat per al teu producte — l'informe resultant.

Recorre criteri a criteri (WCAG, i de vegades la norma EN 301 549 europea o la Secció 508 dels EUA) i marca cadascun amb un nivell de suport:

Per a què serveix: és el document que un comprador (una universitat, una empresa) demana abans de contractar un e-learning. Un ACR honest —que reconeix els seus "Partially Supports"— genera més confiança que un que jura "Supports" en tot. No el confonguis amb l'informe d'auditoria intern (seccions 1-3): l'ACR és de cara a tercers; l'auditoria és la teva llista de feina.

Abans de crear tasques, filtra el soroll (ho vam veure a 06-02):

• Reprodueix la troballa a mà: si axe marca "contrast baix" en un text que resulta estar ocult o sobre imatge decorativa, no és un problema real.
• Verifica el context: un aria-* marcat com a invàlid pot ser correcte per al teu patró concret.
• Creua orígens: si una cosa apareix a l'eina però ni tu a mà ni els usuaris no la noteu, sospita. Si apareix en diversos orígens, és sòlida.

Documenta per què descartes cada fals positiu. Una troballa silenciada sense justificació es converteix, mesos després, en "per què vam ignorar això?".

Una troballa no és accionable fins que és una tasca amb un criteri de "fet" (definition of done) verificable. Compara:

• Malament (no accionable): "Millorar l'accessibilitat del catàleg".
• Bé (accionable): "Donar nom accessible al botó de favorit (button.fav-btn). Fet quan: NVDA anuncia 'Afegeix a preferits, botó' i axe ja no reporta button-name."

El criteri de "fet" ha de dir com es comprova i amb quina prova (automàtica, manual o d'usuari), tancant el cercle amb les tres lliçons anteriors.

Auditoria combinada de Cursalia (axe + llista de comprovació manual de 06-01 + sessió amb usuaris de 06-03). Troballes prioritzades:

Pla de remediació, cada troballa mapejada a la lliçó del curs on és la solució:

Fixa't en dues coses: les tres troballes més greus (P1) van sortir d'usuaris i del manual, no de l'eina — just el missatge del mòdul. I cada tasca remet a on ja vas aprendre a arreglar-la: l'avaluació tanca el bucle amb la construcció.

Arreglar les 6 troballes no serveix de res si d'aquí a dos sprints tornen. Perquè no regressin, l'accessibilitat entra a la Definition of Done de l'equip: una història no està "acabada" fins que compleix criteris d'accessibilitat. Exemple de llista de comprovació de DoD per a Cursalia:

Així es tanca el cercle de tot el Mòdul 6: automàtic per no regressar, manual per al judici, usuaris per a la usabilitat, i informe per prioritzar i verificar. L'accessibilitat deixa de ser una auditoria puntual i es torna part del procés.

• Tractar la severitat de l'eina com a veritat absoluta: pondera-la per impacte real i abast en el teu producte.
• Prioritzar per "el fàcil" en lloc de per impacte: arreglar 20 coses menors mentre un blocador segueix viu és mala gestió (tret que el menor sigui trivial: això sí, cau).
• Confondre ACR amb auditoria interna: l'ACR és per a tercers; l'auditoria és el teu backlog. No els barregis.
• Tancar tasques sense criteri de "fet": "ja ho vaig mirar" no és fet. Defineix com es verifica i amb quina prova.
• No documentar falsos positius: es reobren eternament.
• Arreglar i no blindar: sense accessibilitat a la Definition of Done, tot regressa.
• Consell: a l'informe, ordena per prioritat i posa l'impacte en l'usuari en llenguatge humà ("la Marta no sap si s'ha matriculat"), no només el codi WCAG. Convenç més i prioritza millor.

Exercici 1. axe marca com a "crític" un alt absent en una icona decorativa del footer (apareix a totes les pàgines) i com a "seriós" que el missatge de matrícula amb èxit no s'anunciï (només al flux de compra). Segons el teu criteri d'impacte, quin prioritzes i per què la severitat de l'eina aquí enganya?

Exercici 2. Un client universitari demana "el VPAT de Cursalia" abans de contractar. Explica què li lliures exactament (VPAT vs ACR), quins estats de conformitat pot tenir cada criteri i per què convé ser honest amb els "Partially Supports".

Exercici 3. Converteix aquesta troballa en una tasca accionable amb criteri de "fet": "Contrast del preu insuficient (4.35:1) a la fitxa de curs, WCAG 1.4.3 AA, detectat per Pa11y." Indica també amb quina prova verificaries l'arranjament.

Solució 1. Prioritzes el missatge de matrícula no anunciat, encara que axe el marqui "seriós" i l'alt "crític". Raó: el missatge no anunciat és blocador —la Marta no pot confirmar si es va matricular, al flux de compra, que és essencial i molt usat—, mentre que l'alt en una icona decorativa és menor (un lector la ignora sense perdre informació) per molt que aparegui a totes les pàgines. La severitat de l'eina és genèrica i no sap quina tasca bloqueja cada fallada en el teu producte; cal reinterpretar-la per impacte i abast reals.

Solució 2. Li lliures un ACR: el VPAT (la plantilla de l'ITI) ja emplenat per a Cursalia. Recorre cada criteri WCAG (i possiblement EN 301 549 / Secció 508) marcant-lo com a Supports, Partially Supports, Does Not Support o Not Applicable. Convé ser honest amb els "Partially Supports" perquè un ACR realista genera confiança i evita responsabilitat per afirmacions falses; jurar "Supports" en tot i que després el client trobi barreres destrueix la credibilitat i pot comportar conseqüències contractuals/legals.

Solució 3. Tasca: "Ajustar el color del preu a la fitxa de curs per assolir un contrast ≥ 4.5:1 sobre el seu fons (WCAG 1.4.3 AA)." Criteri de "fet": el comptagotes de contrast de les DevTools marca ✓ AA per a aquell text i Pa11y/axe ja no reporten l'error de contrast a #precio-curso. Verificació: prova automàtica (Pa11y/axe a CI) més una comprovació manual ràpida amb el color picker de 06-01. (El com ajustar el color és del Mòdul 4, lliçó 04-04.)

Amb aquesta lliçó tanques el Mòdul 6: ja no només saps construir interfícies accessibles, sinó verificar que ho són i actuar sobre els resultats. Domines el cicle complet —automàtic, manual, usuaris i informe— sobre pàgines "normals": una fitxa de curs, un catàleg, un formulari de matrícula. Però la web real és més difícil que això. Què passa quan el contingut canvia sense recarregar i cal anunciar-ho (la troballa P1 de la Marta apunta justament allà)? Quan tota l'aplicació és una SPA i la navegació no recarrega la pàgina? Quan Cursalia es tradueix a diversos idiomes i cal gestionar lang, direcció del text i localització? I cap a on va l'estàndard amb WCAG 3.0? Tot això —interaccions complexes i contingut dinàmic, accessibilitat en SPAs, internacionalització/localització i tendències futures— és el Mòdul 7, on portem l'après al terreny avançat.