ACCESIBILIDAD ≠ OVERLAY · 32
Accessibilitat ≠ Overlay: l’accessibilitat també es planifica
2 de novembre de 2026
Un web accessible no és fruit de l’atzar. Cal preveure requisits, disseny inclusiu, desenvolupament, proves i manteniment.
1. Començar des del primer dia
Quan l’accessibilitat es revisa només al final, els problemes ja poden formar part de l’arquitectura i dels components. Corregir-los pot obligar a refer menús o formularis.
Planificar vol dir decidir abans de programar com funcionarà el web sense ratolí, amb lector de pantalla i amb el contingut ampliat.
2. Definir requisits comprovables
Dir que un web serà accessible és massa genèric. Cal especificar navegació amb teclat, focus visible, etiquetes, errors comprensibles i adaptació a pantalles petites.
Les WCAG 2.2 permeten convertir els objectius en criteris d’acceptació i establir qui en verificarà el compliment.
3. Entendre les persones i les tasques
Les persones necessiten trobar informació, comprar, reservar o contactar sense barreres. Aquestes tasques són el centre del projecte.
Cal considerar lectors de pantalla, ampliació, control per veu i altres formes d’interacció, i incorporar persones amb discapacitat quan sigui possible.
4. Dissenyar una estructura coherent
Planifica encapçalaments, enllaços descriptius, navegació previsible i formularis amb instruccions clares. Els components han de comportar-se igual en tot el lloc.
El contrast, el focus i els controls tàctils s’han de decidir durant el disseny, no improvisar després.
5. Desenvolupar amb semàntica correcta
Els botons reals, les etiquetes associades i una estructura HTML lògica ajuden les tecnologies de suport. Els diàlegs i menús dinàmics necessiten una gestió adequada del focus.
Ni WordPress ni Divi ni un connector garanteixen per si sols l’accessibilitat del resultat: cal provar les interaccions.
6. Fer proves durant tot el procés
Comença amb prototips i repeteix les comprovacions al llarg del desenvolupament. Les eines automàtiques no substitueixen les proves manuals.
Comprova teclat, lector de pantalla, zoom, mòbil i tasques completes. Documenta els errors i torna a provar les correccions.
7. Reservar recursos i responsabilitats
La revisió necessita temps, pressupost i persones responsables. Cal decidir qui valida els formularis, els continguts i els components compartits.
Inclou també serveis externs com pagaments o reserves, perquè una sola peça inaccessible pot bloquejar tot el procés.
8. Preveure el manteniment
Les actualitzacions i els continguts nous poden introduir barreres després del llançament. Estableix controls periòdics i un canal per comunicar incidències.
L’accessibilitat acompanya la planificació, el disseny, el desenvolupament, les proves i el manteniment; un overlay no substitueix aquest treball.
9. Un exemple i una acció immediata
En un web de reserves, prova des del principi la selecció de servei, data i confirmació sense ratolí. Defineix com s’anuncien els errors i els canvis.
Per al pròxim projecte, identifica tres tasques essencials, assigna responsables i fixa criteris WCAG 2.2 abans de construir-les.