Més enllà de les WCAG: requisits que s'obliden en webs i apps

Un web que compleix les WCAG 2.1 AA de cap a cap pot no complir l'EN 301 549 (PDF, s'obre en una finestra nova). La raó és a les taules de l'annex A que vas estudiar a la lliçó sobre la presumpció de conformitat: a més del capítol 9, recullen requisits dels capítols 5, 6, 7, 11 i 12 que cap llista de criteris WCAG no conté. Aquesta lliçó se centra en aquesta diferència des del punt de vista de qui audita o encarrega un web o una app: quins requisits «no WCAG» apareixen de debò en els projectes, amb quins exemples i com es comproven.

El mapa de la diferència

La taula resumeix els requisits que falten més sovint als informes. Tots figuren a les taules A.1 o A.2 de la v3.2.1, amb la condició indicada.

Requisits genèrics en webs i apps

5.2: activar sense necessitar el que se supleix

Si el web ofereix el seu propi botó d'«alt contrast» o d'«augmentar el text», aquest mecanisme és una funció d'accessibilitat documentada i s'ha de poder activar sense dependre de la capacitat que supleix. Un commutador d'alt contrast amb una icona gris clar sobre blanc, sense nom accessible i sense accés per teclat incompleix el 5.2 encara que la resta de la pàgina sigui impecable. Comprovació: localitza el control, activa'l només amb teclat i amb lector de pantalla, i mesura'n el contrast.

5.3: sempre més d'un mitjà

El procediment de l'annex C és directe: comprovar que hi ha més d'un mitjà d'identificació o de control. Una app de banca que només permet entrar amb reconeixement facial deixa fora qui no el pot fer servir; si ofereix també PIN o contrasenya, compleix. Comprovació: desactiva la biometria al dispositiu i verifica que l'accés continua sent possible.

5.4: la conversió no pot perdre l'accessibilitat

Molts webs públics converteixen informació: el formulari es transforma en un justificant PDF, un expedient s'exporta a un document, un xat es descarrega com a transcripció. Si el format de destinació admet informació d'accessibilitat (un PDF admet etiquetes, idioma i títol) i la conversió la descarta, s'incompleix el 5.4. Comprovació: genera el document convertit i revisa'l amb el capítol 10; si l'origen tenia estructura i el resultat és un PDF sense etiquetes, ja tens l'incompliment.

Comunicació en temps real i vídeo

Quan un web o una app ofereix veu en els dos sentits, hi entra el capítol 6. Els punts que més es comproven a l'auditoria són:

• Text en temps real (6.2): si hi ha veu bidireccional, hi ha d'haver un mode de text en temps real, que es mostra mentre s'escriu, llevat que afegir-lo exigeixi canviar el maquinari.
• Qualitat del vídeo (6.5): perquè la llengua de signes i la lectura labial siguin viables, la norma exigeix com a mínim resolució QVGA i 12 imatges per segon, recomana VGA i 20 imatges per segon, i limita el desfasament entre veu i vídeo a 100 mil·lisegons.
• Indicadors i identificació (6.2.2 i 6.5.5-6.5.6): indicador visual d'activitat d'àudio i identificació de qui parla.
• Alternatives a la veu (6.4): si hi ha contestador o sistema de resposta de veu interactiva, s'ha de poder fer servir sense sentir-hi ni parlar.

El capítol 7, per la seva banda, avalua el reproductor, no el vídeo. Encara que cada vídeo tingui uns subtítols perfectes (criteri 1.2.2, requisit 9.1.2.2), el reproductor incompleix si no permet mostrar-los (7.1.1), si no deixa ajustar-ne la presentació (7.1.4) o si amaga el botó de subtítols o d'audiodescripció en un submenú mentre el volum és a la barra principal (7.3). Comprovació: reprodueix un vídeo amb teclat i amb lector de pantalla, activa els subtítols i l'audiodescripció i busca les opcions de personalització.

Preferències d'usuari i eines d'autor

L'apartat 11.7 demana que el programari respecti la configuració de la plataforma pel que fa al color, el contrast, el tipus i la mida de lletra i el cursor de focus. En una app nativa es comprova pujant la mida del text del sistema (Text dinàmic a iOS, mida de la lletra a Android) i activant el contrast augmentat: l'app ho ha de reflectir, llevat que l'usuari triï una altra cosa dins de l'app.

L'apartat 11.8 és el més oblidat al sector públic, tot i que molts webs són eines d'autor: aules virtuals, gestors de continguts que fan servir els departaments, plataformes de participació ciutadana o portals d'ocupació on es redacta el currículum. Si el web permet crear contingut per a altres, ha de:

• produir contingut en un format que admeti l'accessibilitat (11.8.1);
• permetre crear-lo accessible, per exemple afegir text alternatiu a una imatge o marcar encapçalaments (11.8.2);
• preservar la informació d'accessibilitat en transformar el contingut (11.8.3);
• oferir ajuda per reparar problemes, com un comprovador (11.8.4);
• si ofereix plantilles, que hi hagi plantilles accessibles (11.8.5).

Documentació i suport: el capítol 12 sempre compta

A les dues taules de l'annex A, els requisits 12.1.1, 12.1.2, 12.2.2, 12.2.3 i 12.2.4 són incondicionals. En una auditoria de web o app això es tradueix en preguntes concretes: l'ajuda explica les funcions d'accessibilitat i la compatibilitat amb lectors de pantalla?, aquesta ajuda és accessible?, el personal d'atenció sap informar-ne?, hi ha un canal que no depengui de la veu o de l'oïda, com un xat, el correu o la videointerpretació en llengua de signes?

Resum

• Complir les WCAG 2.1 AA no és suficient: les taules A.1 i A.2 hi afegeixen requisits dels capítols 5, 6, 7, 11 i 12.
• El 5.2, el 5.3 i el 5.4 apareixen sovint en webs i apps: activació de funcions pròpies, alternativa a la biometria i conversions que no perdin l'accessibilitat.
• El capítol 6 hi entra amb qualsevol veu bidireccional (videoconsulta, videotrucada) i el 7 avalua el reproductor, no el vídeo.
• L'11.7 exigeix respectar les preferències de la plataforma i l'11.8 s'aplica a tot web que serveixi per crear contingut.
• Els requisits del capítol 12 són incondicionals: ajuda accessible i canals de suport adequats en tot projecte.