ACCESSIBILITAT ≠ OVERLAY · 35

L’accessibilitat no es demostra amb una puntuació: es demostra quan les persones poden utilitzar el teu web

📅 6 de novembre del 2026   ·   ⏱ 6 min de lectura

Un 100 % automàtic pot conviure amb barreres greus. El que importa és poder completar tasques reals.

01. Què significa realment una puntuació d’accessibilitat

Una puntuació resumeix un conjunt de comprovacions fetes en unes condicions determinades. No representa totes les persones, dispositius o interaccions. La portada pot obtenir un resultat excel·lent mentre que el procés de reserva, el carretó o l’àrea privada tenen barreres que impedeixen acabar una tasca. És més útil preguntar si les persones poden assolir els seus objectius amb autonomia.

Les puntuacions no són inútils: permeten detectar regressions i seguir problemes tècnics. L’error és interpretar un percentatge com una garantia universal. L’accessibilitat és una qualitat de tot el servei, inclosos els continguts, les interaccions i els resultats que experimenta la persona.

02. Què poden detectar les eines automàtiques

Les eines automàtiques detecten errors que es poden verificar amb regles: alternatives textuals absents, alguns problemes de contrast, camps sense etiqueta, relacions semàntiques incorrectes i atributs mal utilitzats. Són útils per revisar moltes plantilles i controlar canvis després d’una actualització.

Però només cobreixen una part de l’accessibilitat. Analitzar la portada no explica què passa en un diàleg, un missatge d’error o un procés de pagament. Els resultats requereixen interpretació, i moltes advertències necessiten criteri editorial. Que no apareguin errors no demostra que l’experiència sigui inclusiva.

03. Allò que les eines no poden comprendre

Un programa no pot decidir sempre si el text alternatiu transmet la funció real d’una imatge, si unes instruccions són clares sense veure la pantalla o si un recorregut complex és comprensible. Tampoc no pot reproduir totes les combinacions de navegadors, dispositius i tecnologies de suport.

Un enllaç anomenat «fes clic aquí» pot superar algunes comprovacions i continuar sent ambigu quan una persona escolta la llista d’enllaços amb un lector de pantalla. El problema és la manca de context. Cal revisar la finalitat de l’acció i posar-li un nom que anticipi el destí.

04. Quan un 100 % amaga barreres reals

Imagina una botiga que mostra una puntuació perfecta. Els botons tenen nom i les imatges tenen alternatives, però quan s’obre el carretó el focus no entra al diàleg. Qui navega amb teclat no pot tancar-lo i continuar. La compra esdevé impossible malgrat el bon informe.

També hi pot haver errors indicats només amb color vermell, controls que exigeixen arrossegar o confirmacions que desapareixen massa ràpid. Una pàgina estàtica pot semblar impecable mentre falla una interacció essencial. Cal provar tasques completes, no només captures o adreces individuals.

05. La navegació amb teclat com a prova essencial

Deixa el ratolí de banda. Fes servir Tab i Maj+Tab per recórrer enllaços, botons i camps; activa els controls amb Retorn o Espai quan correspongui. Comprova que el focus és visible, segueix un ordre lògic i es gestiona correctament quan s’obren menús o finestres.

Arribar a un control no és suficient: també s’ha de poder activar, tancar i continuar. Un focus atrapat sense sortida, salts inesperats o indicadors invisibles són barreres importants. Documenta els passos exactes i repeteix la prova després de corregir-los.

06. Lectors de pantalla: més enllà de les etiquetes

Un lector de pantalla mostra com s’anuncien els encapçalaments, les regions, els enllaços, els controls i els missatges d’estat. Un text visualment gran no és necessàriament un encapçalament semàntic. Un botó amb una icona sense nom pot resultar incomprensible. L’estructura ha d’ajudar a orientar-se sense veure la pantalla.

Escolta què passa després de cada acció. S’anuncia l’error de validació? S’identifica el camp afectat? Es comunica que s’ha afegit un producte? Es pot tornar al contingut principal? Aquestes preguntes revelen els límits pràctics d’una puntuació global.

07. Formularis, errors i recorreguts complets

Els formularis concentren barreres que els informes automàtics no descriuen completament. Les instruccions poden arribar massa tard, els camps obligatoris poden ser confusos i els errors poden no explicar com recuperar-se. Un formulari usable informa abans de demanar dades i permet corregir-les sense perdre la feina.

Avalua el recorregut des de l’inici fins a la confirmació. No serveix de gaire que la pàgina informativa sigui accessible si el calendari de cites no funciona amb teclat. En una compra, l’èxit és acabar la comanda, no simplement obrir el carretó.

08. Disseny visual, ampliació i comprensió

El contrast, la visibilitat del focus, la mida dels objectius interactius, l’espaiat i l’adaptació a pantalles petites són importants. Prova una ampliació elevada i comprova que la informació essencial continua disponible sense desplaçaments innecessaris en dues direccions. No facis servir només el color per indicar errors.

El llenguatge clar també forma part de l’accessibilitat. Els títols descriptius, els botons amb noms concrets i la navegació coherent ajuden a anticipar resultats. Una interfície que canvia de comportament sense avisar pot ser difícil encara que els controls superin comprovacions tècniques.

09. Les WCAG 2.2: una referència, no un trofeu

Les WCAG 2.2 ofereixen criteris d’èxit verificables i un llenguatge compartit per als equips. Ajuden a definir requisits, auditories i comprovacions. Però un percentatge automàtic no és una declaració de conformitat amb les WCAG. Cap escàner únic pot demostrar que es compleixen tots els criteris aplicables.

Fes servir les pautes dins d’un mètode més ampli: revisió del codi, inspecció manual, proves funcionals i participació de persones amb discapacitat. Una declaració d’accessibilitat responsable ha de descriure l’estat real i les limitacions conegudes.

10. Proves amb persones i tecnologies de suport

Les persones amb discapacitat poden identificar barreres i estratègies que els equips no han previst. Observa tasques realistes i escolta els resultats sense considerar que una sola persona representa totes les situacions. Diferents perfils i tecnologies revelen problemes diferents.

Prepara escenaris com localitzar informació, reservar un servei, canviar una preferència o descarregar un document. Registra què ha passat, on s’ha produït el bloqueig i com afecta l’objectiu. Prioritza els problemes crítics i torna a provar les correccions.

11. Per què un overlay no és la solució

Un overlay pot oferir controls de presentació, però no substitueix l’HTML semàntic, un formulari ben construït o una interacció fiable amb teclat i lector de pantalla. Tampoc no pot decidir si les instruccions són comprensibles o si una transacció funciona de principi a fi.

Instal·lar un giny no fa que un web compleixi automàticament les WCAG 2.2. La interfície afegida també pot necessitar proves. La millora sostenible exigeix corregir el producte original, assignar responsabilitats i mantenir els resultats.

12. Construir un procés de millora contínua

Comença pels recorreguts més importants del web i les plantilles que utilitzen. Combina eines automàtiques amb proves de teclat, focus, estructura, formularis, ampliació i lectors de pantalla. Registra les incidències amb passos reproduïbles, impacte i responsable.

Després incorpora comprovacions a cada publicació i actualització. Revisa els components compartits i les tasques crítiques quan hi hagi canvis. L’objectiu no és mostrar un número en un informe, sinó aconseguir que més persones utilitzin el servei amb autonomia i confiança.