Suport d'accessibilitat i criteri de l'auditor: fallada del lloc o del lector?

Una mateixa pàgina provada amb quatre combinacions de navegador i lector produeix quatre sortides diferents. Part d'aquestes diferències són fallades del lloc; d'altres, maneres legítimes de cada lector de presentar la informació; d'altres, defectes del navegador o del lector; i algunes, errors de configuració del mateix auditor. Separar-les bé és el que dona credibilitat a un informe: reportar com a fallada una indicació de verbositat desacredita l'auditor, i descartar com a «cosa del lector» un control inoperable deixa persones usuàries sense servei. A la lliçó anterior vas aprendre a localitzar la capa del problema; en aquesta aprendràs a decidir què en fas.

Què significa «compatible amb l'accessibilitat»

Com vas veure al curs de metodologia WCAG-EM (s'obre en una finestra nova), el quart requisit de conformitat de les WCAG estableix que, per complir els criteris, només es pot confiar en maneres d'ús de les tecnologies que siguin compatibles amb l'accessibilitat (accessibility supported): han de funcionar amb les tecnologies de suport de les persones usuàries i amb els navegadors disponibles. Les WCAG no diuen quins lectors ni quants; això ho concreta la línia base de cada auditoria, que es fixa i es documenta abans de començar.

D'aquí en surten dues conseqüències pràctiques per a la revisió manual:

• Un codi vàlid segons l'especificació, però que no funciona en les combinacions de la línia base, no serveix per complir. No n'hi ha prou que «l'atribut existeixi a ARIA».
• Un defecte que només apareix amb un lector o navegador que no és a la línia base no converteix el lloc en no conforme, encara que pot merèixer una observació si afecta persones usuàries reals.

Quatre tipus de resultat

1. Fallada del lloc. Falta informació a l'arbre (nom, rol, estat, relació) o el control no es pot fer servir. Sol reproduir-se en totes les combinacions i el codi ho demostra. Veredicte: no compleix, amb el criteri corresponent.
2. Ús no compatible. El codi fa servir una tècnica que la línia base no admet de manera fiable. Exemple típic: un aria-label sobre un span o div sense rol. WAI-ARIA 1.2 (s'obre en una finestra nova) prohibeix donar nom als elements genèrics i els lectors ho tracten de manera desigual. Veredicte: no compleix, amb la recomanació d'una tècnica admesa.
3. Diferència de presentació. La informació arriba, però amb altres paraules, un altre ordre o una altra verbositat. Veredicte: no és una fallada i no es registra com a troballa.
4. Defecte del navegador o del lector amb un codi correcte i una tècnica àmpliament admesa. Si en una combinació de la línia base impedeix o dificulta seriosament la tasca, es registra la troballa indicant la combinació i la causa, amb una recomanació de mitigació si n'hi ha; si és una molèstia menor, com un anunci duplicat, s'anota com a observació.

Diferències legítimes que no són fallades

Cada lector hi afegeix informació pròpia que no prové del lloc. Convé reconèixer-la per no confondre-la amb contingut de la pàgina:

• NVDA pot dir «clicable» quan un element té un gestor de clic. És una pista útil (sovint delata un div que hauria de ser un botó o un enllaç), però la paraula en si no és una fallada: investiga si l'element és operable amb teclat i té rol.
• JAWS indica «a la mateixa pàgina» en els enllaços a àncores i VoiceOver pot dir «visitat».
• TalkBack i VoiceOver hi afegeixen indicacions d'ús, com «fes doble toc per activar», que depenen dels seus ajustos de verbositat.
• L'ordre de nom, rol i estat, la manera d'anunciar la posició («2 de 4») i l'agrupació d'un enllaç amb imatge varien entre lectors.
• Amb nivells baixos de puntuació, alguns signes no es verbalitzen; abans de reportar que «falta» un signe, comprova el nivell configurat.

<!-- No compatible: nom en un element genèric -->
<span aria-label="4 de 5 estrelles">★★★★☆</span>

<!-- Compatible: rol d'imatge amb nom -->
<span role="img" aria-label="4 de 5 estrelles">★★★★☆</span>

Abans de culpar el lloc, revisa el teu equip

Una part de les «troballes» que es descarten en la revisió de qualitat d'un informe neixen al lloc de proves. Comprova aquestes causes abans de registrar res:

• Ajustos de teclat del navegador: Safari i Firefox a macOS no aturen Tab als enllaços sense la configuració que vas veure a la lliçó de teclat.
• Mode del lector: si NVDA és en mode formulari quan hauria de ser en mode navegació, les lletres de navegació ràpida s'escriuen a la pàgina i sembla que «no funcionen».
• Idioma de la veu: si el lector no té instal·lada la veu de l'idioma marcat amb lang, o té desactivat el canvi automàtic d'idioma, no canviarà de veu encara que el codi sigui correcte.
• Versions: els navegadors o lectors desactualitzats produeixen fallades ja corregides; anota sempre les versions.
• Extensions: els gestors de contrasenyes, els bloquejadors i les capes d'accessibilitat (overlays) injecten elements i alteren l'arbre. Audita amb un perfil de navegador net.
• Perfils de verbositat personalitzats: parteix dels ajustos per defecte perquè els teus resultats siguin comparables amb els d'un altre avaluador.

Com decidir: preguntes per ordre

1. Es reprodueix amb la configuració per defecte, versions actualitzades i perfil net? Si no, és un problema del lloc de proves.
2. Falta la informació o l'operació a l'arbre d'accessibilitat? Si falta, és una fallada del lloc.
3. La tècnica utilitzada funciona en les combinacions de la línia base? Si no, és un ús no compatible: no compleix.
4. Impedeix o dificulta seriosament la tasca en alguna combinació de la línia base? Si és així, registra la troballa indicant la combinació i la causa; si no, és una diferència de presentació o una observació.
5. Documenta també el que has descartat. N'hi ha prou amb una línia: «Descartat: anunci duplicat del missatge d'estat a TalkBack; codi correcte; observació». Així qui revisi l'informe sap que es va considerar.

Quan, després d'aquestes preguntes, no puguis determinar el resultat amb seguretat, fes servir el veredicte «no es pot determinar» del protocol, explica què falta per decidir i planifica una prova addicional. Si identifiques un defecte d'un navegador o d'un lector, convé comunicar-lo al seu fabricant pels seus canals públics d'incidències i anotar-ho a l'informe, sense substituir amb això el veredicte sobre el lloc.

Resum

• El requisit de conformitat d'usos compatibles amb l'accessibilitat obliga que la tècnica funcioni a la línia base, no només que sigui vàlida segons l'especificació.
• Classifica cada resultat com a fallada del lloc, ús no compatible, diferència de presentació o defecte del navegador o del lector.
• Les indicacions pròpies dels lectors («clicable», «fes doble toc per activar») no són contingut del lloc, però poden assenyalar una fallada real que cal investigar.
• Abans de registrar una troballa, descarta causes del lloc de proves: mode, idioma de la veu, versions, extensions i ajustos de teclat.
• Decideix amb preguntes per ordre i documenta també el que s'ha descartat i el que no s'ha pogut determinar.