Com fer el vostre lloc web conforme a la WCAG 2.2

Fer el vostre lloc web conforme a la WCAG 2.2 és un procés, no una correcció puntual. La conformitat és el resultat d’un flux de treball repetible: entendre l’estàndard, mesurar on us trobeu, corregir les coses adequades en l’ordre adequat, validar amb tecnologia d’assistència real i usuaris reals, documentar el resultat i evitar que es degradi. Aquesta guia converteix aquest flux de treball en un full de ruta concret, pas a pas, que el vostre equip pot començar a utilitzar avui mateix — sense recórrer a «overlays» d’accessibilitat, que emmascaren els problemes al DOM en lloc de corregir-los i han estat anomenats repetidament en demandes judicials.

Pas 1: Enteneu què requereix realment la WCAG 2.2

Abans d’auditar res, tingueu clar l’objectiu. Les Pautes d’Accessibilitat per al Contingut Web s’organitzen al voltant de quatre principis, resumits en l’acrònim POUR:

Perceivable (Perceptible) — els usuaris han de poder percebre el contingut. Penseu en alternatives textuals per a imatges, subtítols i transcripcions per a mitjans, i contrast de color suficient.
Operable (Operable) — cada funció ha de funcionar sense ratolí. La plena operativitat amb teclat, els indicadors de focus visibles i l’absència de trampes de teclat són requisits fonamentals.
Understandable (Comprensible) — el contingut i el comportament han de ser previsibles. Etiquetes clares, navegació coherent, missatges d’error útils i un llenguatge llegible es troben tots aquí.
Robust (Robust) — el marcatge ha de ser analitzable per la tecnologia d’assistència actual i futura, cosa que a la pràctica significa HTML vàlid i ús correcte de noms, rols i valors ARIA.

Cada principi es desglossa en criteris d’èxit comprovables, i a cada criteri se li assigna un nivell de conformitat: A (essencial), AA (la base legal i pràctica que apunten la majoria d’organitzacions) i AAA (millorat). Quan la gent diu «WCAG 2.2 AA», es refereix a complir cada criteri d’èxit de nivell A i nivell AA. La WCAG 2.2 afegeix nou criteris nous respecte a la 2.1 — inclosos Focus Not Obscured, Dragging Movements, Target Size (Minimum) i Accessible Authentication — la majoria dels quals milloren l’experiència per a usuaris de teclat, de baixa visió i amb dificultats motrius.

Ajuda saber per què aquest és l’objectiu. La conformitat AA està referenciada per les lleis i regulacions que probablement us apliquen: informeu-vos sobre la conformitat WCAG com a estàndard tècnic, i després vegeu com es relaciona amb la European Accessibility Act, l’ADA per a entitats privades i públiques dels EUA, i la Section 508 per a agències federals dels EUA i els seus proveïdors. Si la terminologia us confon pel camí, mantingueu obert en una pestanya el nostre glossari d’accessibilitat.

Dos conceptes més donen forma a qualsevol declaració de conformitat honesta. El primer és l’abast de la conformitat: la conformitat WCAG s’aplica a pàgines completes, no a components aïllats, i a processos complets (p. ex., un flux de pagament sencer) — no podeu afirmar que una pàgina és conforme si un pas d’una tasca de múltiples passos falla. El segon és la tecnologia compatible amb l’accessibilitat: només podeu confiar en maneres d’utilitzar una funció que estiguin realment admeses per la tecnologia d’assistència que tenen els vostres usuaris. A la pràctica això significa provar amb lectors de pantalla i navegadors actuals en lloc de suposar que el marcatge vàlid per si sol garanteix un resultat usable. Tingueu present tots dos mentre delimiteu la vostra feina als passos següents; determinen què podeu afirmar de manera defensable que heu assolit.

Pas 2: Executeu un escaneig automatitzat de referència

No podeu corregir el que no podeu mesurar, així que establiu una línia de base. Les proves automatitzades són ràpides, repetibles i excel·lents per detectar les fallades mecàniques d’alt volum que afecten la majoria de llocs: text alternatiu absent, contrast de color baix, enllaços i botons buits, camps de formulari sense etiqueta, idioma del document absent i identificadors duplicats.

Les eines basades en el motor de codi obert axe-core — inclòs el programari d’escaneig d’accessibilitat de QualiBooth — produeixen una llista prioritzada de problemes en minuts. Si només voleu una lectura ràpida d’on us trobeu, comenceu amb un escaneig d’accessibilitat gratuït d’algunes pàgines clau.

Algunes regles per mantenir la vostra línia de base honesta:

Escanegeu plantilles representatives, no tot el vostre lloc. Proveu la pàgina d’inici, una plantilla de contingut/article, una pàgina de producte o categoria, un formulari (registre, pagament, contacte) i qualsevol tauler autenticat. Corregir una plantilla normalment corregeix centenars de pàgines.
Proveu estats reals, no només la càrrega inicial. Obriu menús, desplegueu acordions, activeu modals i envieu formularis amb errors. Moltes infraccions només apareixen en estats interactius.
Registreu els números. Captureu els recomptes de problemes per gravetat i per criteri d’èxit. Aquest és el vostre punt de referència d’abans/després i la base de la vostra llista pendent de correcció.

Sigueu honestos sobre el sostre: les eines automatitzades detecten de manera fiable només el 30–40% dels problemes WCAG. Un escaneig automatitzat net és necessari, però mai suficient per a una declaració de conformitat real.

Pas 3: Complementeu l’automatització amb una auditoria manual

El 60–70% restant dels criteris WCAG requereix judici humà. Aquest text alternatiu transmet realment el significat de la imatge, o només descriu píxels? L’ordre de lectura i de focus és lògic? Els missatges d’error diuen a l’usuari com recuperar-se? S’anuncia correctament un desplegable personalitzat, i podeu arribar-hi i operar-lo només amb el teclat? Cap motor pot respondre això de manera fiable.

Una auditoria manual estructurada normalment cobreix:

Operació només amb teclat — tabuleu per cada element interactiu; confirmeu un indicador de focus visible, un ordre lògic, l’absència de trampes, i que tot el que podeu fer amb el ratolí ho podeu fer sense ell.
Estructura semàntica — encapçalaments en una jerarquia significativa, fites (landmarks), llistes marcades com a llistes, taules amb encapçalaments adequats.
Formularis — etiquetes programàtiques, camps agrupats, indicació clara dels camps obligatoris, i missatges d’error vinculats als camps que descriuen.
Contingut dinàmic — modals que atrapen i restauren el focus correctament, regions actives (live regions) que anuncien actualitzacions, i ARIA utilitzat només on l’HTML natiu no pot fer la feina.
Qualitat del contingut — text d’enllaç significatiu, contrast suficient en contextos reals, i contingut que no depèn només del color o la forma.

La nostra guia d’auditories manuals d’accessibilitat recorre tota la metodologia, i els problemes d’accessibilitat comuns a evitar són una llista de comprovació ràpida de les fallades que els auditors troben més sovint. Si preferiu que ho fem nosaltres, l’equip de consultoria d’accessibilitat de QualiBooth duu a terme auditories manuals expertes segons els criteris WCAG 2.2 AA.

Pas 4: Prioritzeu i corregiu

Una llarga llista d’infraccions és aclaparadora fins que la seqüencieu. Trieu combinant l’impacte en l’usuari i l’abast:

Primer els bloquejadors. Qualsevol cosa que faci impossible una tasca per a un grup d’usuaris — trampes de teclat, un pagament inaccessible, un formulari d’inici de sessió sense etiqueta — va a dalt de tot independentment de quantes instàncies existeixin.
Després els problemes d’alta freqüència i de tot el lloc. Un problema de contrast o de focus a la capçalera, el peu de pàgina o un component del sistema de disseny es multiplica per cada pàgina. Corregir-lo una vegada ofereix el major rendiment.
Després els problemes específics de pàgina i de contingut. Un text alternatiu absent individual, un únic control mal etiquetat, o un buit d’encapçalament aïllat.

Quan corregiu, arregleu la font, no el símptoma. Preferiu els elements HTML natius als <div> apedaçats amb ARIA; corregiu el component del sistema de disseny en lloc de cada pàgina que l’utilitza; i abordeu les causes arrel a les plantilles i els components compartits perquè la correcció escali. Torneu a escanejar després de cada lot perquè pugueu veure caure els recomptes i evitar introduir regressions. Aquest és també el moment adequat per integrar l’accessibilitat als vostres design tokens — establiu colors segurs per al contrast, una mida mínima d’objectiu de 24×24 px i estils de focus visibles com a valors per defecte perquè la feina nova comenci conforme.

Alguns patrons de correcció es repeteixen prou sovint com per anomenar-los explícitament:

Utilitzeu la plataforma. Un <button>, <a href>, <input>, <select> i <dialog> natiu venen amb comportament de teclat, gestió del focus i un nom accessible correcte de franc. Recorreu a ARIA només per omplir buits genuïns — i recordeu la primera regla d’ARIA: no useu ARIA si un element natiu serveix.
Anomeneu les coses programàticament. Cada control necessita un nom accessible des d’una <label>, aria-label o aria-labelledby — no només text visual proper. Els botons només amb icona són l’infractor més comú.
Gestioneu el focus deliberadament. Quan s’obre un modal, moveu-hi el focus, atrapeu-lo mentre estigui obert, i torneu-lo al desencadenant en tancar. Quan el contingut s’actualitza sense una navegació, utilitzeu una regió activa perquè els usuaris de lectors de pantalla sentin què ha canviat.
No codifiqueu el significat només en color o forma. Combineu el color amb text, icones o patrons perquè la informació sobrevisqui per als usuaris daltònics i de baixa visió.

Feu el seguiment de la correcció al vostre seguidor d’incidències habitual, etiquetat per criteri d’èxit, perquè la feina d’accessibilitat sigui visible al costat de tota la resta en lloc de viure en un full de càlcul separat que es queda obsolet.

Pas 5: Proveu amb tecnologia d’assistència i persones amb discapacitat

La conformitat tracta en darrera instància de si les persones reals poden utilitzar el vostre lloc. Dues capes de validació importen aquí, i no són intercanviables.

Proves amb lector de pantalla. Verifiqueu les vostres correccions amb la tecnologia d’assistència que la gent realment utilitza: NVDA o JAWS amb Chrome/Firefox a Windows, i VoiceOver amb Safari a macOS i iOS. Escolteu noms precisos, rols correctes, canvis d’estat anunciats i un ordre de lectura assenyat. Una avaluació amb lector de pantalla us ofereix una revisió professional de les combinacions principals si el vostre equip no té l’experiència.

Proves d’usabilitat amb usuaris amb discapacitat. Complir cada criteri d’èxit és el terra, no el sostre — un lloc pot ser tècnicament conforme i tot i així frustrant d’utilitzar. El senyal més fiable prové de les auditories per persones amb discapacitat, que proven amb la seva pròpia tecnologia d’assistència i hàbits i fan aflorar barreres que les llistes de comprovació passen per alt. Aquesta és la diferència entre complir la lletra de l’estàndard i oferir veritable accessibilitat digital.

Pas 6: Documenteu la conformitat (declaració i VPAT/ACR)

Un cop hàgiu corregit i validat, captureu el resultat. La documentació és el que converteix el «ho hem intentat» en una afirmació defensable i comunicable.

Declaració d’accessibilitat. Una pàgina pública que indica el vostre objectiu de conformitat (p. ex., WCAG 2.2 AA), descriu què heu fet, enumera qualsevol limitació coneguda, i dona als usuaris una manera de reportar problemes. Moltes regulacions, inclosa l’EAA, n’esperen una.
VPAT / Accessibility Conformance Report. Una Voluntary Product Accessibility Template completada esdevé un ACR — l’artefacte estàndard que els equips de compres i els compradors empresarials sol·liciten com a prova. La nostra guia sobre què és un VPAT/ACR explica el document, i el servei d’informes VPAT produeix un informe precís, recolzat en auditoria, que podeu lliurar a clients i equips jurídics.

Escriviu-los basant-vos en l’evidència dels resultats reals de la vostra auditoria, no en aspiracions. Un VPAT que exagera la conformitat és una responsabilitat, no un actiu.

Pas 7: Mantingueu la conformitat al llarg del temps

L’accessibilitat es degrada en el moment en què un lloc canvia — un component nou, un formulari redissenyat, un giny de tercers o una edició de contingut poden reintroduir barreres silenciosament. La conformitat és un estat que mantingueu, no una fita que superes una sola vegada.

Integreu l’accessibilitat al cicle de vida del vostre programari:

Desplaceu-vos cap a l’esquerra (shift left). Afegiu comprovacions automatitzades al vostre pipeline amb integració d’accessibilitat CI/CD perquè les infraccions es detectin als pull requests, abans que s’enviïn — el lloc més barat possible per corregir-les.
Monitoritzeu la producció. Programeu auditories d’accessibilitat recurrents per detectar regressions i derives de contingut que les comprovacions prèvies al llançament no veuran.
Apodereu el vostre equip. Equipeu dissenyadors, desenvolupadors i autors de contingut amb un kit d’eines d’accessibilitat i estàndards compartits perquè l’accessibilitat sigui el valor per defecte de tothom, no l’afegit posterior d’un especialista.
Governeu a escala. Per a organitzacions grans o de múltiples llocs, una plataforma com Agora centralitza el seguiment, la generació d’informes i la correcció entre equips.

Errors que descarrilen els esforços de conformitat

Els equips que s’encallen ho fan normalment per raons previsibles. Vigileu aquests:

Confiar només en l’automatització. Un informe automatitzat en verd cobreix només un terç dels criteris. Tractar-lo com a prova de conformitat és l’error més comú — i el més arriscat legalment.
Comprar un overlay. Els overlays i els «ginys d’accessibilitat» prometen conformitat instantània injectant JavaScript que sobreescriu la pàgina. No corregeixen el codi subjacent, sovint interfereixen amb la pròpia tecnologia d’assistència dels usuaris, i han estat anomenats en un nombre creixent de queixes. Són una drecera cap al risc, no cap a la conformitat.
Corregir pàgines en lloc de sistemes. Corregir pàgines individuals mentre deixeu el sistema de disseny trencat significa que cada pàgina nova reintrodueix els mateixos defectes. Corregiu primer els components compartits i les plantilles.
Tractar-ho com un projecte puntual. Sense comprovacions CI/CD i auditories recurrents, un lloc conforme s’allunya de la conformitat en uns pocs cicles de llançament.
Ometre els usuaris reals. La conformitat tècnica sense proves d’usabilitat encara pot deixar usuaris amb discapacitat incapaços de completar tasques bàsiques.

Evitar aquests errors evita que la vostra inversió s’esvaeixi en el moment en què el projecte «s’envia».

Posant-ho tot junt

Un camí realista cap a la WCAG 2.2 AA té aquest aspecte: apreneu els principis POUR i l’objectiu AA, executeu una línia de base automatitzada, afegiu-hi una auditoria manual, corregiu per impacte i abast, valideu amb lectors de pantalla i usuaris amb discapacitat, documenteu la vostra conformitat en una declaració i un VPAT, i després mantingueu-la sana amb comprovacions CI/CD i auditories recurrents. Cada pas reforça l’anterior — i res d’això depèn d’un overlay que tapa el codi real.

Comenceu petit i guanyeu impuls: escanegeu un grapat de plantilles aquesta setmana, corregiu els estils de contrast i de focus del vostre sistema de disseny, i poseu una comprovació automatitzada al vostre pipeline. A partir d’aquí, el full de ruta anterior us porta la resta del camí. Quan estigueu preparats per accelerar, exploreu els nostres preus, sol·liciteu una demostració, o parleu amb un expert sobre un pla de correcció adaptat al vostre stack.