Planificar una auditoria: temps, equip i evidències

Una auditoria ben planificada es lliura a temps, es pot defensar i resulta útil per a l'equip que ha de corregir. Una de mal planificada acaba amb l'auditor avaluant a les dues de la matinada la pantalla de pagament sense usuari de proves. Aquesta lliçó tradueix WCAG-EM (s'obre en una finestra nova) a un pla de treball amb fases, estimació de l'esforç, repartiment de tasques i un sistema d'evidències que després alimentarà l'informe.

Fases i lliurables

Estimar l'esforç

L'estimació realista parteix de la mostra. Un ordre de magnitud útil, que cada equip ha d'ajustar amb la seva experiència:

• Pàgina senzilla (text, imatges, navegació compartida): 1-2 hores d'avaluació manual completa a nivell AA la primera vegada; menys per a pàgines que comparteixen plantilla i components ja avaluats.
• Pàgina amb formulari, taula complexa o components ARIA: 2-4 hores.
• Procés complet de 5-6 passos: 4-8 hores, perquè cal recórrer-lo amb teclat, amb dos lectors de pantalla i almenys en mòbil.
• Documents PDF: 1-3 hores per document segons la llargada i l'estructura.

A això s'hi sumen l'exploració (10-15 % del total), l'anàlisi i la redacció (25-35 %) i la presentació. Un error típic és oblidar els temps de preparació dels entorns: instal·lar versions concretes de NVDA, actualitzar JAWS, disposar d'un iPhone i un Android reals (els emuladors no substitueixen VoiceOver ni TalkBack).

Equip i rols

WCAG-EM recomana que l'avaluador conegui a fons les WCAG, les tecnologies web i les tecnologies de suport. En equips de més d'una persona convé repartir per competències:

• Auditor principal: abast, mostra, decisions de criteri, informe final i defensa davant del client.
• Avaluadors: proves per pàgina i criteri, registre d'evidències. Si n'hi ha diversos, cadascun assumeix pàgines completes (no criteris solts) per mantenir el context, i es calibren al principi avaluant junts dues pàgines i comparant-ne els resultats.
• Especialista en tecnologies de suport: idealment una persona usuària real de lector de pantalla o de control per veu. La seva revisió detecta problemes d'usabilitat que un auditor vident passa per alt, tot i que cal recordar que la conformitat la decideix el criteri, no l'experiència d'una persona.
• Revisor: algú que no ha avaluat revisa l'informe buscant-hi incoherències (el mateix problema amb dos criteris diferents, severitats incoherents, captures sense context).

Acordeu des del principi un vocabulari comú de veredictes (compleix, no compleix, no es pot determinar, no aplicable i no comprovat) i de severitats, i un únic full de registre per evitar haver de conciliar formats al final.

Eines de registre

Per a auditories petites n'hi ha prou amb un full de càlcul amb una fila per troballa: identificador, pàgina o estat, criteri WCAG (número i nom), nivell, descripció, passos per reproduir-la, resultat esperat, resultat observat, tecnologia amb què es va detectar, severitat, evidència (enllaç a la captura o al vídeo), recomanació. Per a auditories grans, moltes organitzacions fan servir una eina específica o un gestor d'incidències (Jira, GitLab) on cada troballa és un tiquet que l'equip de desenvolupament pot tancar; això facilita la reauditoria.

La WCAG-EM Report Tool del W3C és adequada per estructurar l'informe pels cinc passos i permet exportar a JSON per conservar i reutilitzar l'avaluació.

Evidències: què cal recollir i com

L'evidència és el que converteix una opinió en una troballa. Per a cada problema convé recollir:

1. Captura de pantalla anotada amb l'element assenyalat i, si escau, l'estat (menú obert, error de validació). Inclou-hi l'URL i la data en el nom del fitxer o en l'anotació.
2. Fragment de codi rellevant tal com el lliura el navegador (DOM inspeccionat, no el codi font del servidor), per exemple l'<img> sense alt o el <div onclick> sense funció ni tabindex.
3. Sortida de la tecnologia de suport: el text del visor de veu de NVDA o de l'historial de veu de JAWS, o un vídeo curt amb l'àudio del lector de pantalla.
4. Resultat de l'eina automàtica si l'error el detecta (identificador de regla d'axe, informe de WAVE), amb l'advertiment que l'eina confirma, no decideix.
5. Mesura quan el criteri és quantitatiu: ràtio de contrast amb els dos colors en hexadecimal, mida de l'objectiu en píxels CSS, amplada a la qual es trenca el reajustament.

Riscos habituals i com cobrir-los

• Entorns que canvien durant l'auditoria: acorda una finestra de congelació o avalua en preproducció amb una versió etiquetada; anota la data i la versió en cada evidència.
• Sense dades de prova: demana usuaris, targetes i certificats de prova al document d'abast; sense ells, els processos en queden fora i l'informe ho ha de dir.
• Abast que creix: qualsevol pàgina afegida passa pel procediment de mostra i es registra com a ampliació.
• Contingut de tercers: identifica'l en l'exploració i acorda com es tracta a l'informe.
• Protecció de dades: no facis servir dades reals de ciutadans ni les desis en captures; si avalues en producció amb un compte real, anonimitza les evidències.

Resum

• Planifica en cinc fases amb lliurables clars: abast signat, inventari i mostra, resultats, esborrany de l'informe i informe final.
• Estima a partir de la mostra: l'avaluació manual i la redacció són la major part de l'esforç; la part automàtica és petita.
• Reparteix per pàgines completes, calibra l'equip al principi i reserva un revisor que no hagi avaluat.
• Registra cada troballa amb criteri, passos, esperat/observat, tecnologia, severitat i evidència reproduïble.
• Cobreix els riscos: entorn congelat, dades de prova, abast controlat, contingut de tercers i protecció de dades.