Cómo auditar la accesibilidad de tu web en 2 horas: stack open-source y checklist EAA

Por el equipo de Kiwop · Agencia Digital especializada en Desarrollo de Software e Inteligencia Artificial aplicada · Publicado el 7 de mayo de 2026 · Última actualización: 7 de mayo de 2026

TL;DR — El deadline de la European Accessibility Act fue el 28 de junio de 2025. La mayoría de webs siguen sin cumplir. Este post te da el framework práctico: 5 herramientas open-source que cubren ~70% de fallos automatizables, una auditoría completa en 2 horas, y un checklist EAA priorizado por impacto legal. Sin consultores, sin presupuesto especial. Solo stack probado y comandos copiables.

Cuando la European Accessibility Act entró en vigor el 28 de junio de 2025, la reacción más común en los equipos técnicos fue: "lo miramos la semana que viene". Diez meses después, la mayoría de esas webs siguen igual. El informe WebAIM Million 2024 lo confirmó antes incluso del deadline: el 94,8% de las páginas de inicio analizadas tenía fallos WCAG detectables automáticamente.

El problema no es falta de voluntad. Es falta de un punto de entrada claro. Sabes que tienes que cumplir WCAG 2.2 AA, sabes que hay herramientas, pero no tienes claro por dónde empezar, cuánto tiempo requiere, ni cómo priorizar lo que encuentres.

Este artículo es ese punto de entrada. Si ya leíste nuestra guía sobre la normativa EAA, plazos y sanciones, esto es el paso siguiente: el procedimiento técnico concreto. Si no la leíste, hazlo primero — aquí asumimos que tienes claro qué te exige la ley y nos centramos en cómo ejecutarlo.

Por qué auditar AHORA (y no la semana que viene)

El estado real del cumplimiento EAA en 2026

El deadline pasó. No es una amenaza futura: la EAA ya es ley aplicable en todos los estados miembros de la UE que transpusieron la directiva antes del 28 de junio de 2025. Y las cifras de cumplimiento son alarmantes.

El WebAIM Million 2024 analizó las 1.000.000 páginas de inicio más visitadas. Resultado: el 94,8% tenía al menos un fallo WCAG 2.1 AA detectable automáticamente — y eso antes de contar los fallos que solo afloran en revisión manual. Los errores más comunes: bajo contraste de color (81% de páginas), texto alternativo ausente (54,5%), etiquetas de formulario faltantes (48,6%), enlaces vacíos (44,6%) y botones sin nombre accesible (28,2%).

Dicho de otra forma: casi con certeza tu web tiene todos esos problemas. La pregunta no es si cumples, sino cuántos criterios incumples y con qué gravedad.

El riesgo legal concreto

El portal oficial de la Comisión Europea sobre la EAA es claro: la normativa aplica a cualquier empresa que ofrezca productos o servicios digitales a consumidores en la UE, independientemente de su sede. Las sanciones las fija cada estado miembro, pero la directiva exige que sean "efectivas, proporcionadas y disuasorias". En varios países ya se contemplan multas de hasta 100.000 euros por infracción.

Más allá de las multas: cualquier persona con discapacidad que no pueda acceder a tu servicio puede presentar una queja formal ante el organismo de supervisión de su país. La carga de la prueba recae sobre la empresa — tienes que demostrar que cumples, no ellos que no cumples.

Qué exige el regulador (y qué no)

Lo que exige es conformidad con WCAG 2.2 nivel AA y una declaración de accesibilidad pública. Lo que no exige es perfección total ni una auditoría anual firmada por una empresa certificadora. Exige un nivel de diligencia razonable, documentado.

Lo que no te salva: un overlay JavaScript que se superpone a tu web prometiendo accesibilidad automática. La FTC multó a accessiBe con 1 millón de dólares por publicidad engañosa exactamente en ese punto. Ningún organismo regulador acepta un overlay como evidencia de cumplimiento.

El primer paso real de esa diligencia es la auditoría. Y puedes hacerla en 2 horas con las herramientas correctas.

El stack: 5 herramientas open-source que cubren ~70% de WCAG 2.2 AA

Antes de ver el proceso, entiende el límite fundamental de cualquier herramienta automática: detectan aproximadamente el 30-40% de los problemas reales de accesibilidad. Lo dice la guía de auditorías de accesibilidad del W3C. El resto requiere revisión manual — navegación por teclado, lectores de pantalla, juicio humano.

¿Por qué entonces empezar con herramientas automáticas? Porque te permiten eliminar sistemáticamente la capa más gruesa de errores en minutos, liberando tiempo para la revisión manual donde realmente está el valor.

axe-core (Deque) — el motor estándar de la industria

axe-core es la librería open-source de Deque Systems que hoy alimenta prácticamente todas las herramientas de testing de accesibilidad de la industria. Lo usan Chrome DevTools, Storybook, Playwright, Cypress y decenas de frameworks de CI. No es una opción entre muchas: es el motor.

Su ventaja principal no es la cobertura — es la tasa de falsos positivos prácticamente cero. Cuando axe reporta un error, es un error real. Cuando no reporta nada, no significa que estés limpio; significa que los errores que no detecta están en ese 60-70% que necesita revisión manual.

Puedes usar axe de tres formas:

Como extensión de navegador (axe DevTools Free): instala la extensión en Chrome o Firefox, abre tu página, ejecuta el análisis. Resultado en segundos. Cero configuración. Ideal para el primer contacto.

Como librería en tests: integra axe-core directamente en tu suite de tests con Playwright o Cypress:

Via CLI con @axe-core/cli:

Lighthouse — el complemento gratuito de Chrome

Lighthouse incluye una auditoría de accesibilidad en su informe estándar, basada también en axe-core, pero con cobertura adicional de métricas de rendimiento y algunas comprobaciones propias.

Su puntuación de accesibilidad (0-100) no equivale a porcentaje de cumplimiento WCAG. Es una medida relativa que sirve como referencia. Lo realmente útil es la lista de issues categorizada que genera.

Puedes ejecutarlo desde:

• Chrome DevTools → Lighthouse → Categoría "Accesibilidad"
• CLI: npx lighthouse https://tu-web.com --only-categories=accessibility --output json
• PageSpeed Insights: https://pagespeed.web.dev/ (gratis, sin instalar nada)

La documentación oficial de Lighthouse de accesibilidad de Google documenta exactamente qué comprueba cada criterio y cómo calcula la puntuación. Léela una vez para no malinterpretar los resultados.

Pa11y — auditoría desde CLI/CI

Pa11y es la herramienta de línea de comandos diseñada para integrarse en pipelines de CI/CD. Puede auditar una sola URL, un sitemap completo o una lista de páginas, y exportar resultados en múltiples formatos.

Pa11y usa htmlcs por defecto, pero puede configurarse para usar axe-core como motor:

La ventaja de Pa11y sobre ejecutar axe manualmente es que maneja bien páginas con JavaScript asíncrono, autenticación básica y sitios de múltiples páginas sin tener que escribir scripts propios.

NVDA + VoiceOver — los lectores de pantalla reales

Ninguna herramienta automática puede reemplazar pasar 20 minutos navegando tu web con un lector de pantalla. Los resultados son siempre reveladores — y siempre diferentes a lo que esperabas.

NVDA (Windows, gratuito): el lector de pantalla más usado en entornos Windows. Descárgalo desde nvaccess.org. Los atajos fundamentales para una auditoría rápida:

VoiceOver (macOS/iOS, incluido en el sistema): actívalo con Cmd + F5. Para una auditoría rápida en macOS:

Lo que buscas con ambos lectores: ¿anuncia correctamente el tipo de cada elemento (botón, enlace, campo)? ¿Los formularios tienen etiquetas? ¿Las imágenes tienen alt útil? ¿El orden de lectura tiene sentido?

WAVE (browser extension) — checks visuales rápidos

La extensión WAVE de WebAIM superpone iconos visuales directamente sobre la página indicando errores, alertas y elementos estructurales. Es la forma más rápida de tener una visión visual de los problemas sin salir del navegador.

Especialmente útil para:

• Ver en un vistazo la jerarquía de headings (¿saltas de H1 a H4?)
• Detectar zonas de bajo contraste en contexto visual
• Identificar formularios sin label antes de ejecutar axe
• Verificar que los landmarks ARIA están bien definidos (header, nav, main, footer)

No la uses como herramienta principal — tiene más falsos positivos que axe. Úsala como primer vistazo visual antes de ejecutar las otras.

Paso a paso: tu primera auditoría en 2 horas

Este protocolo cubre las páginas más críticas de tu sitio: home, una página de listado, una página de detalle, y el flujo de conversión principal (contacto, registro o compra). Con las 2 horas distribuidas así:

Minuto 0-15: Setup → Minuto 15-45: automatización → Minuto 45-90: revisión manual → Minuto 90-120: priorización y reporte

Minuto 0-15: setup

Antes de lanzar herramientas, define exactamente qué páginas vas a auditar. Una auditoría que intenta cubrir todo el sitio de golpe acaba sin cubrir nada bien.

Lista mínima recomendada para una primera auditoría:

1. Home (/)
2. Una página de listado o categoría representativa
3. Una página de detalle o servicio representativa
4. Página de contacto o formulario principal
5. Una página de checkout o registro (si aplica)

Con esa lista, instala las herramientas:

Instala también la extensión WAVE en Chrome o Firefox, y descarga NVDA si estás en Windows (o activa VoiceOver en macOS con Cmd + F5).

Minuto 15-45: ejecución automatizada (axe + Lighthouse + Pa11y)

Ejecuta las tres herramientas sobre cada URL de tu lista. El orden importa: empieza con axe porque su output es el más limpio, luego Lighthouse para la vista de rendimiento + accesibilidad combinada, y Pa11y para validar con un segundo motor.

Mientras se ejecutan, abre cada URL en Chrome con la extensión WAVE activa. Anota visualmente los patrones que ves antes de leer los reports.

Cuando terminen los scripts, abre los JSON con cualquier visor o simplemente cuenta las violaciones:

Minuto 45-90: tests manuales con lectores de pantalla

Esta es la parte que más aporta y que más suelen saltar. No la saltes.

Protocolo de 20 minutos con NVDA o VoiceOver (repite para cada página crítica):

1. Navega solo con Tab desde el principio de la página. ¿El primer elemento es "saltar al contenido principal" (skip link)? ¿El foco es visible en todo momento? ¿El orden tiene sentido lógico?

1. Abre el listado de headings (Insert + F7 en NVDA, rotor en VoiceOver). ¿Hay un H1? ¿La jerarquía es coherente? ¿Hay headings en elementos que visualmente no son headings?

1. Activa el modo formulario si hay formularios. Rellena el formulario usando solo el teclado. ¿Cada campo anuncia su etiqueta? ¿Los errores de validación se anuncian correctamente? ¿Puedes enviar el formulario?

1. Navega por links (tecla K en NVDA). ¿Todos los links tienen texto descriptivo fuera de contexto? ¿Ninguno dice "clic aquí", "ver más" o "leer"?

1. Escucha las imágenes. Cuando el foco llega a una imagen, ¿el texto alternativo describe su contenido o función? ¿Las imágenes decorativas se ignoran (alt="")?

Documenta cada problema que encuentres con: URL, elemento afectado, criterio WCAG que incumple, y prioridad (la veremos en el siguiente paso).

Minuto 90-120: priorización y reporte

Tienes dos fuentes de issues: los reports automáticos y tus notas manuales. El trabajo ahora es unificarlos y priorizarlos por impacto legal y de usuario.

No intentes resolver nada todavía. El objetivo de las 2 horas es diagnóstico, no remediación.

Para el reporte, crea un documento con esta estructura mínima:

Cómo interpretar los resultados: priorización por impacto legal

El mayor error al interpretar una auditoría de accesibilidad es tratar todos los issues igual. Un bajo contraste en un texto de pie de página tiene consecuencias muy distintas a que un formulario de registro no sea operable con teclado.

La matriz de priorización combina dos ejes: severidad para el usuario (¿bloquea el uso?) y exposición legal (¿afecta a flujos críticos que el regulador examinaría primero?).

Issues críticos (bloquean cumplimiento)

Un issue es crítico cuando impide completar una tarea a un usuario con discapacidad o cuando afecta a un flujo que el regulador examinaría prioritariamente (registro, compra, contacto, acceso a servicio).

Los candidatos habituales:

• Formularios no accesibles por teclado: el criterio WCAG 2.1.1 (Teclado) es de nivel A — el nivel mínimo. No cumplirlo en el formulario de contacto es un bloqueo de cumplimiento directo.
• Imágenes funcionales sin alt: una imagen que es un enlace o un botón sin texto alternativo deja al usuario de lector sin información para actuar. Criterio 1.1.1.
• Botones sin nombre accesible: <button><svg>...</svg></button> sin aria-label. El botón existe, el usuario sabe que está ahí, pero no sabe qué hace. Criterio 4.1.2.
• Video con audio sin subtítulos: si tienes vídeos con información en audio, el criterio 1.2.2 exige subtítulos sincronizados. La ausencia es bloqueante y de alta visibilidad.

Issues mayores (alto riesgo de queja)

Un issue es mayor cuando dificulta significativamente el uso pero no lo bloquea completamente, o cuando afecta a páginas de alta visibilidad aunque el impacto individual sea parcial.

• Bajo contraste en texto principal: criterio 1.4.3. Un ratio inferior a 4,5:1 en cuerpo de texto afecta a usuarios con baja visión y usuarios en condiciones de luz difícil (que no son solo personas con discapacidad declarada).
• Jerarquía de headings rota: saltar de H1 a H4, usar headings solo por estilo visual, o no tener H1. Afecta a lectores de pantalla y a usuarios cognitivos que navegan por estructura. Criterio 1.3.1.
• Focus visible ausente: si el outline del focus está eliminado globalmente con *:focus { outline: none; }, la navegación por teclado se vuelve opaca. Criterio 2.4.7 (AA) y 2.4.11 (AA en WCAG 2.2).
• Mensajes de error sin ARIA live regions: cuando un formulario valida y muestra errores, ¿el lector de pantalla los anuncia automáticamente? Si no, el usuario no sabe que algo fue mal. Criterio 3.3.1.

Issues menores (mejoras)

Un issue es menor cuando tiene impacto limitado, afecta a elementos secundarios, o requiere juicio de contexto para determinar si realmente es un problema.

• Alt descriptivo pero impreciso en imágenes decorativas o de apoyo.
• Contraste ligeramente inferior al mínimo en textos de pie de página o disclaimers.
• Roles ARIA redundantes que no causan daño pero no añaden valor.
• Textos de enlace contextuales (que tienen sentido con el texto de alrededor, aunque no solos).

No ignores los menores indefinidamente — acaban acumulándose. Pero no bloquees la remediación de críticos por resolver menores primero.

Lo que las herramientas NO detectan (y debes hacer manual)

Aquí está el 60-70% que axe, Pa11y y Lighthouse no ven. Este bloque es el que diferencia una auditoría real de un check automático y un clic en "compartir". La documentación del W3C sobre evaluación de accesibilidad lo detalla con rigor; aquí va la versión práctica.

Texto alternativo "decorativo" mal usado: axe verifica que las imágenes tienen alt, pero no puede saber si el texto alternativo describe correctamente el contenido. "Imagen 1" o el nombre del archivo pasan el check automático y son un fallo real.

Orden de tabulación lógico: Tab recorre los elementos interactivos en el orden del DOM. Si tu CSS reordena visualmente los elementos, el orden de tabulación puede ser caótico. Ninguna herramienta lo detecta — solo navegando con Tab.

Etiquetas de formulario asociadas correctamente: axe detecta labels ausentes, pero no detecta labels que están en el HTML pero no están asociadas al campo correcto (ya sea por for/id incorrectos o por proximity association mal implementada).

Textos de enlace contextuales: WCAG permite links cuyo texto ("ver más") tiene sentido en contexto gracias al texto de alrededor (criterio 2.4.4 — En Contexto). Axe no puede evaluar si ese contexto es suficiente. Solo un humano puede juzgarlo.

Lectura del flujo en lector de pantalla: el orden de lectura de un lector de pantalla sigue el DOM, no la presentación visual. Layouts con CSS Grid o Flexbox que reordenan elementos visualmente pueden generar un flujo de lectura incomprensible que ninguna herramienta automática detecta.

Subtítulos y transcripciones de vídeo: axe detecta si existe un elemento <track> en un <video>, pero no puede verificar si los subtítulos son precisos, completos o están bien sincronizados. Eso requiere revisión humana.

Gestos complejos sin alternativa: si tu interfaz tiene funciones activadas por gestos de múltiples dedos (pinch, swipe) sin alternativa de teclado o toque simple, es una violación del criterio 2.5.1. Las herramientas de escritorio no lo detectan.

ARIA mal usado: axe detecta ARIA inválido, pero no detecta ARIA técnicamente válido que rompe la semántica. Un role="presentation" en un elemento interactivo, o un aria-hidden="true" en contenido relevante, pasan el check automático y son fallos graves.

Reportar en formato de cumplimiento EAA

Una auditoría que no genera documentación útil es una auditoría a medias. El regulador no pide un test de axe; pide evidencia de diligencia. La GOV.UK accessibility guidance — referencia del sector aunque sea de ámbito UK — documenta el estándar de facto para declaraciones de accesibilidad que varios reguladores europeos han adoptado como referencia.

Estructura del informe que pide la administración

Un informe de auditoría de accesibilidad que puedas presentar ante el regulador (o que te sirva de base para tu declaración) debe incluir:

1. Alcance: qué páginas se auditaron, por qué se eligieron esas, y qué tecnologías de asistencia se usaron para la revisión manual.
2. Metodología: herramientas automatizadas (versiones exactas), proceso de revisión manual (lectores de pantalla, versiones de navegador).
3. Estándar evaluado: WCAG 2.2 nivel AA / EN 301 549.
4. Hallazgos: lista de criterios incumplidos, con evidencia (capturas, fragmentos de HTML), clasificados por severidad.
5. Estado de cumplimiento: conformidad total, parcial o no conforme — con justificación.
6. Excepciones documentadas: si hay contenido de terceros incontrolable (widget externo, mapa incrustado), documentarlo como excepción temporal con plan de resolución.
7. Fecha de la auditoría y frecuencia de revisión.

Plantilla de declaración de accesibilidad

La declaración de accesibilidad es el documento público que la EAA exige publicar en tu web (habitualmente en una URL como /accesibilidad o en el footer). Estructura mínima:

Cómo documentar excepciones temporales

Si tienes contenido que no cumple pero no puedes remediar inmediatamente (widget de chat de tercero, mapa embebido, PDF legado), la EAA permite documentarlo como excepción temporal con condiciones:

• Describir el contenido afectado y el criterio WCAG incumplido.
• Justificar por qué es una carga desproporcionada resolverlo inmediatamente.
• Indicar la fecha prevista de resolución o la alternativa accesible disponible.
• Actualizar la declaración cuando se resuelva.

Una excepción documentada es protección legal. Una excepción sin documentar, no.

Mantener el cumplimiento: integración en CI

La auditoría puntual te dice dónde estás hoy. La integración en CI te dice si lo que publicas mañana rompe lo que arreglaste ayer. Sin CI de accesibilidad, la remediación es un cubo con fugas.

axe-core en GitHub Actions / GitLab CI

El bloque de CI más básico con axe y Playwright:

Y el test correspondiente:

Si tu proyecto usa React o cualquier otro framework SPA, asegúrate de que el test espera a que el contenido dinámico se haya renderizado antes de ejecutar axe — usa page.waitForSelector o page.waitForLoadState('networkidle').

Pa11y dashboard

Pa11y tiene un dashboard web open-source que permite monitorizar la accesibilidad de un sitio completo en el tiempo y ver la evolución de los issues por página. Es especialmente útil para:

• Sitios con muchas páginas generadas dinámicamente (blogs, e-commerce).
• Equipos donde los resultados los consulta gente no técnica.
• Auditorías programadas semanales o mensuales sin intervención manual.

Para proyectos más pequeños, Pa11y CI con output JSON y un archivo de configuración versionado en el repo suele ser suficiente:

El parámetro threshold permite fijar un número máximo de violaciones aceptable antes de fallar el build — útil cuando estás en proceso de remediación y quieres evitar regresiones sin bloquear cada PR.

Pull request gating

La forma más efectiva de mantener el cumplimiento es bloqueando merges de PRs que introducen nuevas violaciones. El flujo recomendado:

1. El workflow de CI ejecuta axe sobre las páginas afectadas por el PR.
2. Si hay nuevas violaciones (comparado con la rama base), el check falla.
3. El PR no puede mergearse hasta que las violaciones nuevas se resuelvan o se documente la excepción.

La clave es auditar solo páginas afectadas — auditar todo el sitio en cada PR es demasiado lento. Una estrategia práctica: mapear qué componentes afecta cada PR y auditar las páginas que usan esos componentes.

Este modelo de QA automation integrado en el ciclo de desarrollo es el mismo que aplicamos a otros tipos de calidad: rendimiento, seguridad, cobertura de tests.

Métricas a monitorizar

Las métricas que realmente importan para el seguimiento de accesibilidad en el tiempo:

Errores comunes en remediación

La auditoría es la mitad del trabajo. La remediación es donde más equipos cometen errores que crean nuevos problemas o dan falsa sensación de cumplimiento.

Error 1: solo arreglar lo que detecta axe

Si remedias únicamente los issues automáticos, estás cubriendo el 30-40% del problema y dejando el 60-70% sin tocar. El regulador no acepta "pasamos axe sin errores" como evidencia de cumplimiento WCAG. Pasa el check automático Y la revisión manual.

Error 2: texto alternativo automático con IA sin review

Varios tools de accesibilidad y CMSs ofrecen generación automática de alt text con IA. El resultado puede ser técnicamente presente (lo que satisface a axe) pero semánticamente inútil o incorrecto. Un alt generado por IA que describe "una persona usando un ordenador portátil en una oficina" cuando la imagen muestra un diagrama de arquitectura técnica pasa el check automático y falla el criterio real. Revisa siempre los alts generados.

Error 3: ARIA roles innecesarios que rompen el árbol

El antipatrón más común al intentar "mejorar" la accesibilidad: añadir roles ARIA a elementos que ya tienen semántica nativa correcta. <button role="button"> es redundante. <nav role="navigation"> es redundante. Pero <div role="button"> en lugar de <button> rompe el árbol de accesibilidad porque el div no tiene el comportamiento de teclado del botón nativo. La regla general: usa HTML semántico nativo antes de añadir ARIA. ARIA es para casos que el HTML no cubre, no para decorar HTML existente.

Error 4: cambiar markup sin re-testear con NVDA

Cada cambio de HTML que afecte a estructura, roles, landmarks o orden de elementos puede cambiar la experiencia en lector de pantalla de forma no obvia. Un cambio que mejora la puntuación de axe puede empeorar la navegación real. Re-testa con NVDA o VoiceOver cada vez que modificas la estructura semántica de una página, no solo cuando hagas cambios específicos de accesibilidad.

Error 5: arreglar sin entender el criterio

"Añade aria-label a los botones" es una instrucción que puede interpretarse literalmente y aplicarse en exceso. Si un botón ya tiene texto visible descriptivo, añadir aria-label puede contradecirlo y confundir al lector de pantalla (el criterio 2.5.3 — Label in Name — exige que el aria-label contenga el texto visible). Antes de aplicar una corrección, lee el criterio WCAG que justifica el cambio en la spec oficial del W3C.

Preguntas frecuentes

¿Es suficiente con WCAG AA o necesito AAA?

La EAA exige WCAG 2.2 nivel AA. El nivel AAA no es obligatorio por ley. Dicho esto, algunos criterios AAA son muy simples de implementar y ofrecen mejoras significativas para ciertos grupos de usuarios (como el criterio 2.4.12 — Focus Appearance — que exige mayor visibilidad del foco). Si llegas a AA sin esfuerzo extra, revisa si algún criterio AAA específico es relevante para tu audiencia. Pero no conviertas AAA en un objetivo de cumplimiento normativo — no lo es.

¿Qué pasa si tengo un widget de terceros que no cumple?

Es uno de los escenarios más comunes y más incómodos. Si el widget está en un flujo crítico (chat de soporte, pasarela de pago, formulario de registro), tienes tres opciones: sustituirlo por uno accesible, proporcionar una alternativa accesible equivalente, o documentarlo como excepción temporal con fecha de resolución. Lo que no puedes hacer es ignorarlo — la ley te hace responsable de la experiencia completa que ofreces al usuario, incluidos los componentes que no controlas directamente. Si el proveedor del widget no tiene roadmap de accesibilidad, ese es un criterio de selección de proveedor.

¿Cuánto cuesta una auditoría profesional?

Una auditoría profesional independiente — la que genera un informe formal con valor legal para presentar al regulador — oscila generalmente entre 3.000 y 15.000 euros para un sitio de tamaño medio, dependiendo del número de páginas, la complejidad de las interacciones y si incluye testing con usuarios reales con discapacidad.

La auditoría de 2 horas que describes este post no es equivalente a una auditoría profesional. Es un diagnóstico de alto nivel que te permite saber dónde estás y priorizar. Sirve como base para la remediación interna. Si necesitas el informe formal para presentar ante el regulador o para un proceso legal, necesitas una auditoría profesional. En Kiwop hacemos auditorías formales de accesibilidad — si estás en ese punto, hablamos.

¿La auditoría debe repetirse?

Sí, y en dos niveles. El nivel automático (axe en CI) debe ejecutarse con cada PR que modifique componentes de UI. El nivel completo (automatización + revisión manual con lectores de pantalla + revisión de flujos) debe repetirse al menos una vez al año y siempre que haya cambios significativos de diseño, nuevas funcionalidades principales, o cambio de tecnología de renderizado.

La accesibilidad no es un estado que se alcanza y se mantiene solo. Es un proceso continuo — exactamente igual que el rendimiento o la seguridad.

¿Mi PDF o documento también debe cumplir?

Sí. La EAA no aplica solo a HTML. Los documentos descargables (PDF, Word, Excel) que son parte de un servicio digital también deben ser accesibles si contienen información relevante para el usuario. Los PDFs accesibles requieren estructura de encabezados, orden de lectura correcto, alt text en imágenes, y texto real (no imagen escaneada). Herramientas: PAC 2024 (PDF Accessibility Checker, gratuito) y el verificador de accesibilidad integrado en Adobe Acrobat. Si tu sitio ofrece documentación, contratos, facturas o formularios en PDF, inclúyelos en la auditoría.

Conclusión: el cumplimiento es un proceso, no un evento

Si hay una lección que resume todo lo anterior es esta: la accesibilidad se mantiene igual que el software — con tests automatizados que detectan regresiones, revisiones periódicas que validan lo que la automatización no ve, y documentación que demuestra diligencia.

El deadline de la EAA pasó. No puedes deshacer eso. Lo que sí puedes hacer es empezar hoy, con el stack que tienes, en 2 horas, y construir desde ahí. Una auditoría imperfecta hecha hoy es infinitamente más valiosa que una auditoría perfecta que nunca se ejecuta.

El camino es: diagnóstico (este post) → remediación priorizada → integración en CI → auditoría formal si tu exposición legal lo requiere.

Si en algún punto del camino necesitas apoyo externo — una auditoría formal, una remediación compleja, o integrar la accesibilidad en el proceso de Desarrollo de Software de tu equipo desde el principio — en Kiwop hacemos exactamente eso. Cuéntanos dónde estás y te decimos por dónde empezar.