Com auditar l'accessibilitat de la teva web en 2 hores: stack open-source i checklist EAA

Per l'equip de Kiwop · Agència Digital especialitzada en Desenvolupament de Programari i Intel·ligència Artificial aplicada · Publicat el 7 de maig de 2026 · Última actualització: 7 de maig de 2026

TL;DR — El termini de la European Accessibility Act va ser el 28 de juny de 2025. La majoria de webs segueixen sense complir. Aquest post et dona el framework pràctic: 5 eines open-source que cobreixen ~70% de fallades automatitzables, una auditoria completa en 2 hores, i un checklist EAA prioritzat per impacte legal. Sense consultors, sense pressupost especial. Només stack provat i comandes copiables.

Quan la European Accessibility Act va entrar en vigor el 28 de juny de 2025, la reacció més freqüent als equips tècnics va ser: "ho mirem la setmana que ve". Deu mesos després, la majoria d'aquelles webs segueixen igual. L'informe WebAIM Million 2024 ho va confirmar fins i tot abans del termini: el 94,8% de les pàgines d'inici analitzades tenia fallades WCAG detectables automàticament.

El problema no és falta de voluntat. És falta d'un punt d'entrada clar. Saps que has de complir WCAG 2.2 AA, saps que hi ha eines, però no tens clar per on començar, quant temps requereix, ni com prioritzar el que trobis.

Aquest article és aquell punt d'entrada. Si ja vas llegir la nostra guia sobre la normativa EAA, terminis i sancions, això és el pas següent: el procediment tècnic concret. Si no la vas llegir, fes-ho primer — aquí assumim que tens clar què t'exigeix la llei i ens centrem en com executar-ho.

Per què auditar ARA (i no la setmana que ve)

L'estat real del compliment EAA el 2026

El termini ha passat. No és una amenaça futura: la EAA ja és llei aplicable a tots els estats membres de la UE que van transposar la directiva abans del 28 de juny de 2025. I les xifres de compliment són alarmants.

El WebAIM Million 2024 va analitzar 1.000.000 pàgines d'inici de les més visitades. Resultat: el 94,8% tenia almenys una fallada WCAG 2.1 AA detectable automàticament — i això abans de comptar les fallades que només afloren en revisió manual. Els errors més comuns: baix contrast de color (81% de pàgines), text alternatiu absent (54,5%), etiquetes de formulari absents (48,6%), enllaços buits (44,6%) i botons sense nom accessible (28,2%).

Dit d'una altra manera: gairebé amb certesa la teva web té tots aquells problemes. La pregunta no és si complixes, sinó quants criteris incompleixes i amb quina gravetat.

El risc legal concret

El portal oficial de la Comissió Europea sobre la EAA és clar: la normativa aplica a qualsevol empresa que ofereixi productes o serveis digitals a consumidors a la UE, independentment de la seva seu. Les sancions les fixa cada estat membre, però la directiva exigeix que siguin "efectives, proporcionades i dissuasòries". En diversos països ja es contemplen multes de fins a 100.000 euros per infracció.

Més enllà de les multes: qualsevol persona amb discapacitat que no pugui accedir al teu servei pot presentar una queixa formal davant l'organisme de supervisió del seu país. La càrrega de la prova recau sobre l'empresa — has de demostrar que complixes, no ells que no complixes.

Què exigeix el regulador (i què no)

El que exigeix és conformitat amb WCAG 2.2 nivell AA i una declaració d'accessibilitat pública. El que no exigeix és perfecció total ni una auditoria anual signada per una empresa certificadora. Exigeix un nivell de diligència raonable, documentat.

El que no et salva: un overlay JavaScript que se superposa a la teva web prometent accessibilitat automàtica. La FTC va multar accessiBe amb 1 milió de dòlars per publicitat enganyosa exactament en aquest punt. Cap organisme regulador accepta un overlay com a evidència de compliment.

El primer pas real d'aquella diligència és l'auditoria. I pots fer-la en 2 hores amb les eines correctes.

El stack: 5 eines open-source que cobreixen ~70% de WCAG 2.2 AA

Abans de veure el procés, entén el límit fonamental de qualsevol eina automàtica: detecten aproximadament el 30-40% dels problemes reals d'accessibilitat. Ho diu la guia d'auditories d'accessibilitat del W3C. La resta requereix revisió manual — navegació per teclat, lectors de pantalla, judici humà.

Per què, doncs, començar amb eines automàtiques? Perquè et permeten eliminar sistemàticament la capa més gruixuda d'errors en minuts, alliberant temps per a la revisió manual on realment hi ha el valor.

axe-core (Deque) — el motor estàndard de la indústria

axe-core és la llibreria open-source de Deque Systems que avui alimenta pràcticament totes les eines de testing d'accessibilitat de la indústria. L'usen Chrome DevTools, Storybook, Playwright, Cypress i desenes de frameworks de CI. No és una opció entre moltes: és el motor.

El seu principal avantatge no és la cobertura — és la taxa de falsos positius pràcticament zero. Quan axe reporta un error, és un error real. Quan no reporta res, no significa que estiguis net; significa que els errors que no detecta estan en aquell 60-70% que necessita revisió manual.

Pots usar axe de tres formes:

Com a extensió de navegador (axe DevTools Free): instal·la l'extensió a Chrome o Firefox, obre la teva pàgina, executa l'anàlisi. Resultat en segons. Zero configuració. Ideal per al primer contacte.

Com a llibreria en tests: integra axe-core directament a la teva suite de tests amb Playwright o Cypress:

Via CLI amb @axe-core/cli:

Lighthouse — el complement gratuït de Chrome

Lighthouse inclou una auditoria d'accessibilitat a l'informe estàndard, basada també en axe-core, però amb cobertura addicional de mètriques de rendiment i algunes comprovacions pròpies.

La seva puntuació d'accessibilitat (0-100) no equival a percentatge de compliment WCAG. És una mesura relativa que serveix com a referència. El que és realment útil és la llista d'issues categoritzada que genera.

Pots executar-lo des de:

• Chrome DevTools → Lighthouse → Categoria "Accessibilitat"
• CLI: npx lighthouse https://la-teva-web.com --only-categories=accessibility --output json
• PageSpeed Insights: https://pagespeed.web.dev/ (gratuït, sense instal·lar res)

La documentació oficial de Lighthouse d'accessibilitat de Google documenta exactament què comprova cada criteri i com calcula la puntuació. Llegeix-la una vegada per no malinterpretar els resultats.

Pa11y — auditoria des de CLI/CI

Pa11y és l'eina de línia de comandes dissenyada per integrar-se en pipelines de CI/CD. Pot auditar una sola URL, un sitemap complet o una llista de pàgines, i exportar resultats en múltiples formats.

Pa11y usa htmlcs per defecte, però es pot configurar per usar axe-core com a motor:

L'avantatge de Pa11y sobre executar axe manualment és que gestiona bé pàgines amb JavaScript asíncron, autenticació bàsica i llocs de múltiples pàgines sense haver d'escriure scripts propis.

NVDA + VoiceOver — els lectors de pantalla reals

Cap eina automàtica pot substituir passar 20 minuts navegant la teva web amb un lector de pantalla. Els resultats són sempre reveladors — i sempre diferents al que esperaves.

NVDA (Windows, gratuït): el lector de pantalla més usat en entorns Windows. Descarrega'l des de nvaccess.org. Les tecles fonamentals per a una auditoria ràpida:

VoiceOver (macOS/iOS, inclòs al sistema): activa'l amb Cmd + F5. Per a una auditoria ràpida a macOS:

El que busques amb tots dos lectors: anuncia correctament el tipus de cada element (botó, enllaç, camp)? Els formularis tenen etiquetes? Les imatges tenen alt útil? L'ordre de lectura té sentit?

WAVE (browser extension) — checks visuals ràpids

L'extensió WAVE de WebAIM superposa icones visuals directament sobre la pàgina indicant errors, alertes i elements estructurals. És la forma més ràpida de tenir una visió visual dels problemes sense sortir del navegador.

Especialment útil per a:

• Veure d'un cop d'ull la jerarquia de headings (saltes de H1 a H4?)
• Detectar zones de baix contrast en context visual
• Identificar formularis sense label abans d'executar axe
• Verificar que els landmarks ARIA estan ben definits (header, nav, main, footer)

No l'usis com a eina principal — té més falsos positius que axe. Usa-la com a primer cop d'ull visual abans d'executar les altres.

Pas a pas: la teva primera auditoria en 2 hores

Aquest protocol cobreix les pàgines més crítiques del teu lloc: home, una pàgina de llistat, una pàgina de detall, i el flux de conversió principal (contacte, registre o compra). Amb les 2 hores distribuïdes així:

Minut 0-15: setup → Minut 15-45: automatització → Minut 45-90: revisió manual → Minut 90-120: priorització i report

Minut 0-15: setup

Abans de llançar eines, defineix exactament quines pàgines vas a auditar. Una auditoria que intenta cobrir tot el lloc de cop acaba sense cobrir res bé.

Llista mínima recomanada per a una primera auditoria:

1. Home (/)
2. Una pàgina de llistat o categoria representativa
3. Una pàgina de detall o servei representativa
4. Pàgina de contacte o formulari principal
5. Una pàgina de checkout o registre (si aplica)

Amb aquella llista, instal·la les eines:

Instal·la també l'extensió WAVE a Chrome o Firefox, i descarrega NVDA si estàs a Windows (o activa VoiceOver a macOS amb Cmd + F5).

Minut 15-45: execució automatitzada (axe + Lighthouse + Pa11y)

Executa les tres eines sobre cada URL de la teva llista. L'ordre importa: comença amb axe perquè el seu output és el més net, després Lighthouse per a la vista de rendiment + accessibilitat combinada, i Pa11y per validar amb un segon motor.

Mentre s'executen, obre cada URL a Chrome amb l'extensió WAVE activa. Anota visualment els patrons que veus abans de llegir els reports.

Quan acabin els scripts, obre els JSON amb qualsevol visor o simplement compta les violacions:

Minut 45-90: tests manuals amb lectors de pantalla

Aquesta és la part que més aporta i que més solen saltar. No la saltis.

Protocol de 20 minuts amb NVDA o VoiceOver (repeteix per a cada pàgina crítica):

1. Navega només amb Tab des del principi de la pàgina. ¿El primer element és "saltar al contingut principal" (skip link)? ¿El focus és visible en tot moment? ¿L'ordre té sentit lògic?

1. Obre el llistat de headings (Insert + F7 a NVDA, rotor a VoiceOver). ¿Hi ha un H1? ¿La jerarquia és coherent? ¿Hi ha headings en elements que visualment no són headings?

1. Activa el mode formulari si hi ha formularis. Omple el formulari usant només el teclat. ¿Cada camp anuncia la seva etiqueta? ¿Els errors de validació s'anuncien correctament? ¿Pots enviar el formulari?

1. Navega per links (tecla K a NVDA). ¿Tots els links tenen text descriptiu fora de context? ¿Cap diu "fes clic aquí", "veure més" o "llegir"?

1. Escolta les imatges. Quan el focus arriba a una imatge, ¿el text alternatiu descriu el seu contingut o funció? ¿Les imatges decoratives s'ignoren (alt="")?

Documenta cada problema que trobis amb: URL, element afectat, criteri WCAG que incompleix, i prioritat (la veurem al pas següent).

Minut 90-120: priorització i report

Tens dues fonts d'issues: els reports automàtics i les teves notes manuals. La feina ara és unificar-les i prioritzar-les per impacte legal i d'usuari.

No intents resoldre res encara. L'objectiu de les 2 hores és diagnòstic, no remediació.

Per al report, crea un document amb aquesta estructura mínima:

Com interpretar els resultats: priorització per impacte legal

El major error en interpretar una auditoria d'accessibilitat és tractar tots els issues igual. Un baix contrast en un text de peu de pàgina té conseqüències molt diferents a que un formulari de registre no sigui operable amb teclat.

La matriu de priorització combina dos eixos: severitat per a l'usuari (bloqueja l'ús?) i exposició legal (afecta a fluxos crítics que el regulador examinaria primer?).

Issues crítics (bloquegen el compliment)

Un issue és crític quan impedeix completar una tasca a un usuari amb discapacitat o quan afecta a un flux que el regulador examinaria prioritàriament (registre, compra, contacte, accés a servei).

Els candidats habituals:

• Formularis no accessibles per teclat: el criteri WCAG 2.1.1 (Teclat) és de nivell A — el nivell mínim. No complir-lo al formulari de contacte és un bloqueig de compliment directe.
• Imatges funcionals sense alt: una imatge que és un enllaç o un botó sense text alternatiu deixa l'usuari de lector sense informació per actuar. Criteri 1.1.1.
• Botons sense nom accessible: <button><svg>...</svg></button> sense aria-label. El botó existeix, l'usuari sap que hi és, però no sap què fa. Criteri 4.1.2.
• Vídeo amb àudio sense subtítols: si tens vídeos amb informació en àudio, el criteri 1.2.2 exigeix subtítols sincronitzats. L'absència és bloquejant i d'alta visibilitat.

Issues majors (alt risc de queixa)

Un issue és major quan dificulta significativament l'ús però no el bloqueja completament, o quan afecta a pàgines d'alta visibilitat tot i que l'impacte individual sigui parcial.

• Baix contrast en text principal: criteri 1.4.3. Un ràtio inferior a 4,5:1 en cos de text afecta usuaris amb baixa visió i usuaris en condicions de llum difícil (que no són només persones amb discapacitat declarada).
• Jerarquia de headings trencada: saltar de H1 a H4, usar headings només per estil visual, o no tenir H1. Afecta lectors de pantalla i usuaris cognitius que naveguen per estructura. Criteri 1.3.1.
• Focus visible absent: si l'outline del focus s'ha eliminat globalment amb *:focus { outline: none; }, la navegació per teclat es torna opaca. Criteri 2.4.7 (AA) i 2.4.11 (AA a WCAG 2.2).
• Missatges d'error sense ARIA live regions: quan un formulari valida i mostra errors, ¿el lector de pantalla els anuncia automàticament? Si no, l'usuari no sap que alguna cosa ha anat malament. Criteri 3.3.1.

Issues menors (millores)

Un issue és menor quan té impacte limitat, afecta a elements secundaris, o requereix judici de context per determinar si realment és un problema.

• Alt descriptiu però imprecís en imatges decoratives o de suport.
• Contrast lleugerament inferior al mínim en textos de peu de pàgina o disclaimers.
• Rols ARIA redundants que no causen dany però no afegeixen valor.
• Textos d'enllaç contextuals (que tenen sentit amb el text del voltant, tot i que no sols).

No ignoris els menors indefinidament — acaben acumulant-se. Però no bloquegis la remediació de crítics per resoldre menors primer.

El que les eines NO detecten (i has de fer manual)

Aquí hi ha el 60-70% que axe, Pa11y i Lighthouse no veuen. Aquest bloc és el que diferencia una auditoria real d'un check automàtic i un clic a "compartir". La documentació del W3C sobre avaluació d'accessibilitat ho detalla amb rigor; aquí va la versió pràctica.

Text alternatiu "decoratiu" mal usat: axe verifica que les imatges tenen alt, però no pot saber si el text alternatiu descriu correctament el contingut. "Imatge 1" o el nom del fitxer passen el check automàtic i són una fallada real.

Ordre de tabulació lògic: Tab recorre els elements interactius en l'ordre del DOM. Si el teu CSS reordena visualment els elements, l'ordre de tabulació pot ser caòtic. Cap eina ho detecta — només navegant amb Tab.

Etiquetes de formulari associades correctament: axe detecta labels absents, però no detecta labels que estan al HTML però no estan associades al camp correcte (ja sigui per for/id incorrectes o per proximity association mal implementada).

Textos d'enllaç contextuals: WCAG permet links el text dels quals ("veure més") té sentit en context gràcies al text del voltant (criteri 2.4.4 — En Context). Axe no pot avaluar si aquell context és suficient. Només un humà pot jutjar-ho.

Lectura del flux en lector de pantalla: l'ordre de lectura d'un lector de pantalla segueix el DOM, no la presentació visual. Layouts amb CSS Grid o Flexbox que reordenen elements visualment poden generar un flux de lectura incomprensible que cap eina automàtica detecta.

Subtítols i transcripcions de vídeo: axe detecta si existeix un element <track> en un <video>, però no pot verificar si els subtítols són precisos, complets o estan ben sincronitzats. Això requereix revisió humana.

Gestos complexos sense alternativa: si la teva interfície té funcions activades per gestos de múltiples dits (pinch, swipe) sense alternativa de teclat o toc simple, és una violació del criteri 2.5.1. Les eines d'escriptori no ho detecten.

ARIA mal usat: axe detecta ARIA invàlid, però no detecta ARIA tècnicament vàlid que trenca la semàntica. Un role="presentation" en un element interactiu, o un aria-hidden="true" en contingut rellevant, passen el check automàtic i són fallades greus.

Reportar en format de compliment EAA

Una auditoria que no genera documentació útil és una auditoria a mitges. El regulador no demana un test d'axe; demana evidència de diligència. La GOV.UK accessibility guidance — referència del sector tot i ser d'àmbit UK — documenta l'estàndard de facto per a declaracions d'accessibilitat que diversos reguladors europeus han adoptat com a referència.

Estructura de l'informe que demana l'administració

Un informe d'auditoria d'accessibilitat que puguis presentar davant el regulador (o que et serveixi de base per a la teva declaració) ha d'incloure:

1. Abast: quines pàgines s'han auditat, per què s'han triat aquelles, i quines tecnologies d'assistència s'han usat per a la revisió manual.
2. Metodologia: eines automatitzades (versions exactes), procés de revisió manual (lectors de pantalla, versions de navegador).
3. Estàndard avaluat: WCAG 2.2 nivell AA / EN 301 549.
4. Troballes: llista de criteris incomplerts, amb evidència (captures, fragments de HTML), classificats per severitat.
5. Estat de compliment: conformitat total, parcial o no conforme — amb justificació.
6. Excepcions documentades: si hi ha contingut de tercers incontrolable (widget extern, mapa incrustat), documentar-lo com a excepció temporal amb pla de resolució.
7. Data de l'auditoria i freqüència de revisió.

Plantilla de declaració d'accessibilitat

La declaració d'accessibilitat és el document públic que la EAA exigeix publicar a la teva web (habitualment en una URL com /accessibilitat o al footer). Estructura mínima:

Com documentar excepcions temporals

Si tens contingut que no compleix però no pots remediar immediatament (widget de xat de tercers, mapa incrustat, PDF llegat), la EAA permet documentar-lo com a excepció temporal amb condicions:

• Descriure el contingut afectat i el criteri WCAG incomplert.
• Justificar per què és una càrrega desproporcionada resoldre-ho immediatament.
• Indicar la data prevista de resolució o l'alternativa accessible disponible.
• Actualitzar la declaració quan es resolgui.

Una excepció documentada és protecció legal. Una excepció sense documentar, no.

Mantenir el compliment: integració en CI

L'auditoria puntual et diu on ets avui. La integració en CI et diu si el que publiques demà trenca el que vas arreglar ahir. Sense CI d'accessibilitat, la remediació és un cubell amb fuites.

axe-core en GitHub Actions / GitLab CI

El bloc de CI més bàsic amb axe i Playwright:

I el test corresponent:

Si el teu projecte usa React o qualsevol altre framework SPA, assegura't que el test espera que el contingut dinàmic s'hagi renderitzat abans d'executar axe — usa page.waitForSelector o page.waitForLoadState('networkidle').

Pa11y dashboard

Pa11y té un dashboard web open-source que permet monitoritzar l'accessibilitat d'un lloc complet en el temps i veure l'evolució dels issues per pàgina. És especialment útil per a:

• Llocs amb moltes pàgines generades dinàmicament (blogs, e-commerce).
• Equips on els resultats els consulta gent no tècnica.
• Auditories programades setmanals o mensuals sense intervenció manual.

Per a projectes més petits, Pa11y CI amb output JSON i un fitxer de configuració versionat al repo sol ser suficient:

El paràmetre threshold permet fixar un nombre màxim de violacions acceptable abans de fallar el build — útil quan estàs en procés de remediació i vols evitar regressions sense bloquejar cada PR.

Pull request gating

La forma més efectiva de mantenir el compliment és bloquejant merges de PRs que introdueixen noves violacions. El flux recomanat:

1. El workflow de CI executa axe sobre les pàgines afectades pel PR.
2. Si hi ha noves violacions (comparades amb la branca base), el check falla.
3. El PR no pot fer-se merge fins que les violacions noves es resolguin o es documenti l'excepció.

La clau és auditar només pàgines afectades — auditar tot el lloc en cada PR és massa lent. Una estratègia pràctica: mapar quins components afecta cada PR i auditar les pàgines que fan servir aquells components.

Aquest model de QA automation integrat en el cicle de desenvolupament és el mateix que apliquem a altres tipus de qualitat: rendiment, seguretat, cobertura de tests.

Mètriques a monitoritzar

Les mètriques que realment importen per al seguiment de l'accessibilitat en el temps:

Errors comuns en remediació

L'auditoria és la meitat del treball. La remediació és on més equips cometen errors que creen nous problemes o donen falsa sensació de compliment.

Error 1: arreglar només el que detecta axe

Si remedies únicament els issues automàtics, estàs cobrint el 30-40% del problema i deixant el 60-70% sense tocar. El regulador no accepta "passem axe sense errors" com a evidència de compliment WCAG. Passa el check automàtic I la revisió manual.

Error 2: text alternatiu automàtic amb IA sense revisió

Diverses eines d'accessibilitat i CMSs ofereixen generació automàtica d'alt text amb IA. El resultat pot ser tècnicament present (el que satisfà axe) però semànticament inútil o incorrecte. Un alt generat per IA que descriu "una persona usant un ordinador portàtil en una oficina" quan la imatge mostra un diagrama d'arquitectura tècnica passa el check automàtic i falla el criteri real. Revisa sempre els alts generats.

Error 3: rols ARIA innecessaris que trenquen l'arbre

L'antipatró més comú quan s'intenta "millorar" l'accessibilitat: afegir rols ARIA a elements que ja tenen semàntica nativa correcta. <button role="button"> és redundant. <nav role="navigation"> és redundant. Però <div role="button"> en lloc de <button> trenca l'arbre d'accessibilitat perquè el div no té el comportament de teclat del botó natiu. La regla general: usa HTML semàntic natiu abans d'afegir ARIA. ARIA és per als casos que l'HTML no cobreix, no per decorar HTML existent.

Error 4: canviar el markup sense re-testar amb NVDA

Cada canvi de HTML que afecti a estructura, rols, landmarks o ordre d'elements pot canviar l'experiència en lector de pantalla de forma no òbvia. Un canvi que millora la puntuació d'axe pot empitjorar la navegació real. Re-testa amb NVDA o VoiceOver cada vegada que modifiques l'estructura semàntica d'una pàgina, no només quan facis canvis específics d'accessibilitat.

Error 5: arreglar sense entendre el criteri

"Afegeix aria-label als botons" és una instrucció que es pot interpretar literalment i aplicar en excés. Si un botó ja té text visible descriptiu, afegir aria-label pot contradir-lo i confondre el lector de pantalla (el criteri 2.5.3 — Label in Name — exigeix que l'aria-label contingui el text visible). Abans d'aplicar una correcció, llegeix el criteri WCAG que justifica el canvi a la spec oficial del W3C.

Preguntes freqüents

És suficient amb WCAG AA o necessito AAA?

La EAA exigeix WCAG 2.2 nivell AA. El nivell AAA no és obligatori per llei. Dit això, alguns criteris AAA són molt senzills d'implementar i ofereixen millores significatives per a certs grups d'usuaris (com el criteri 2.4.12 — Focus Appearance — que exigeix major visibilitat del focus). Si arribes a AA sense esforç extra, revisa si algun criteri AAA específic és rellevant per a la teva audiència. Però no converteixis AAA en un objectiu de compliment normatiu — no ho és.

Què passa si tinc un widget de tercers que no compleix?

És un dels escenaris més comuns i més incòmodes. Si el widget és en un flux crític (xat de suport, passarel·la de pagament, formulari de registre), tens tres opcions: substituir-lo per un d'accessible, proporcionar una alternativa accessible equivalent, o documentar-lo com a excepció temporal amb data de resolució. El que no pots fer és ignorar-ho — la llei et fa responsable de l'experiència completa que ofereixes a l'usuari, inclosos els components que no controles directament. Si el proveïdor del widget no té roadmap d'accessibilitat, aquest és un criteri de selecció de proveïdor.

Quant costa una auditoria professional?

Una auditoria professional independent — la que genera un informe formal amb valor legal per presentar al regulador — oscil·la generalment entre 3.000 i 15.000 euros per a un lloc de mida mitjana, depenent del nombre de pàgines, la complexitat de les interaccions i si inclou testing amb usuaris reals amb discapacitat.

L'auditoria de 2 hores que descriu aquest post no és equivalent a una auditoria professional. És un diagnòstic d'alt nivell que et permet saber on ets i prioritzar. Serveix com a base per a la remediació interna. Si necessites l'informe formal per presentar davant el regulador o per a un procés legal, necessites una auditoria professional. A Kiwop fem auditories formals d'accessibilitat — si estàs en aquell punt, parlem.

L'auditoria s'ha de repetir?

Sí, i en dos nivells. El nivell automàtic (axe en CI) s'ha d'executar amb cada PR que modifiqui components de UI. El nivell complet (automatització + revisió manual amb lectors de pantalla + revisió de fluxos) s'ha de repetir almenys una vegada a l'any i sempre que hi hagi canvis significatius de disseny, noves funcionalitats principals, o canvi de tecnologia de renderitzat.

L'accessibilitat no és un estat que s'assoleix i es manté sol. És un procés continu — exactament igual que el rendiment o la seguretat.

El meu PDF o document també ha de complir?

Sí. La EAA no aplica només a HTML. Els documents descarregables (PDF, Word, Excel) que formen part d'un servei digital també han de ser accessibles si contenen informació rellevant per a l'usuari. Els PDFs accessibles requereixen estructura de capçaleres, ordre de lectura correcte, alt text en imatges, i text real (no imatge escanejada). Eines: PAC 2024 (PDF Accessibility Checker, gratuït) i el verificador d'accessibilitat integrat a Adobe Acrobat. Si el teu lloc ofereix documentació, contractes, factures o formularis en PDF, inclou-los a l'auditoria.

Conclusió: el compliment és un procés, no un esdeveniment

Si hi ha una lliçó que resumeix tot l'anterior és aquesta: l'accessibilitat es manté igual que el software — amb tests automatitzats que detecten regressions, revisions periòdiques que validen el que l'automatització no veu, i documentació que demostra diligència.

El termini de la EAA ha passat. No pots desfer això. El que sí pots fer és començar avui, amb el stack que tens, en 2 hores, i construir des d'allà. Una auditoria imperfecta feta avui és infinitament més valuosa que una auditoria perfecta que mai no s'executa.

El camí és: diagnòstic (aquest post) → remediació prioritzada → integració en CI → auditoria formal si la teva exposició legal ho requereix.

Si en algun punt del camí necessites suport extern — una auditoria formal, una remediació complexa, o integrar l'accessibilitat en el procés de Desenvolupament de Programari del teu equip des del principi — a Kiwop fem exactament això. Explica'ns on ets i et diem per on començar.