IRA y hallazgos WCAG: cómo estructurar los resultados

VERSIÓN EN ESPAÑOL

¿Qué es un hallazgo de accesibilidad y por qué importa tanto documentarlo bien?

Imagina que eres médico y, después de hacer una batería de pruebas a un paciente, anotas en su historial «no se encuentra bien». Sin más detalles. Sin pruebas, sin datos, sin localización del problema. ¿Sería útil ese historial para otro profesional que necesite tratar al paciente? Obviamente, no. Pues exactamente lo mismo ocurre con los hallazgos de accesibilidad en un Informe de Remediación de Accesibilidad (IRA).

Un hallazgo de accesibilidad es cada incumplimiento, error o área de mejora detectada al evaluar un sitio web o aplicación frente a las pautas WCAG 2.1 del W3C. Pero el hallazgo en sí no vale nada si no está bien documentado. Un IRA con hallazgos mal estructurados es como un mapa sin leyenda: técnicamente existe, pero no te lleva a ninguna parte.

Personalmente, creo que la calidad de un IRA se mide directamente por la calidad de sus hallazgos. He visto informes de 200 páginas que no servían para nada porque los hallazgos eran vagos, y he visto informes de 30 páginas que transformaron la accesibilidad de una organización entera porque cada hallazgo era claro, accionable y bien priorizado.

Anatomía de un hallazgo IRA bien estructurado

¿Qué elementos debe tener cada hallazgo para que sea realmente útil? Después de años redactando informes de remediación de accesibilidad, he llegado a una estructura que funciona de forma consistente:

¿Te parece demasiado detalle? Piensa en ello como en una receta de cocina: si solo dice «pon cosas en el horno», el resultado es impredecible. Si dice «precalienta a 180°C, coloca la bandeja en la rejilla central durante 25 minutos», cualquiera puede replicar el resultado con éxito.

Clasificación de hallazgos según niveles WCAG

No todos los hallazgos tienen la misma gravedad. Las pautas WCAG 2.1 del W3C establecen tres niveles de conformidad, y tu IRA debe reflejar esta jerarquía:

Nivel A: lo básico imprescindible

Los criterios de Nivel A representan el mínimo absoluto. Si tu sitio web no cumple estos criterios, estás excluyendo activamente a personas con discapacidad. Según datos de WebAIM en su informe anual WebAIM Million de 2025, el 95,9% de las páginas de inicio analizadas tenían al menos un error de Nivel A detectable automáticamente. Herramientas como axe DevTools de Deque Systems pueden identificar muchos de estos problemas de forma instantánea.

Ejemplos típicos: imágenes sin texto alternativo (1.1.1), vídeos sin subtítulos (1.2.2), formularios sin etiquetas (1.3.1), contenido no navegable con teclado (2.1.1).

Nivel AA: el estándar de referencia

El Nivel AA es el que exige la mayoría de legislaciones, incluida la Directiva Europea de Accesibilidad y el European Accessibility Act. Cuando hablamos de «cumplir WCAG», casi siempre nos referimos al Nivel AA. Tu IRA debe prestar especial atención a estos criterios porque son los que determinan el cumplimiento legal.

Ejemplos: contraste de color insuficiente (1.4.3), texto no redimensionable (1.4.4), navegación inconsistente (3.2.3), mensajes de error sin sugerencias (3.3.3).

Nivel AAA: la excelencia

El Nivel AAA rara vez se exige legalmente, pero incluirlo en tu IRA demuestra compromiso real con la accesibilidad. Personalmente, recomiendo documentar oportunidades de mejora AAA como «hallazgos de mejora», diferenciándolos de los incumplimientos obligatorios.

Herramientas para detectar y documentar hallazgos

¿Con qué herramientas puedes identificar hallazgos para tu IRA? La realidad es que necesitas combinar evaluación automática y manual:

Según Deque Systems, las herramientas automáticas como axe DevTools pueden detectar entre el 30% y el 57% de los problemas de accesibilidad. El resto requiere evaluación manual experta. Tu IRA debe indicar claramente qué metodología se utilizó para cada hallazgo.

Priorización de hallazgos: la clave de un IRA accionable

¿De qué sirve tener 150 hallazgos documentados si el equipo de desarrollo no sabe por dónde empezar? La priorización es lo que convierte un IRA de un documento pasivo en una hoja de ruta activa.

La matriz que utilizo y recomiendo cruza dos variables:

• Impacto en el usuario: ¿cuánto afecta este problema a la experiencia de las personas con discapacidad?
• Esfuerzo de remediación: ¿cuánto tiempo y recursos se necesitan para corregirlo?

Con este cruce obtienes cuatro cuadrantes claros:

Personalmente, siempre aconsejo empezar por los quick wins. Nada motiva más a un equipo que ver resultados rápidos. Un hallazgo como «botón sin etiqueta accesible» puede corregirse en cinco minutos y mejorar la experiencia de miles de usuarios.

Errores comunes al documentar hallazgos en un IRA

¿Quieres saber qué diferencia un IRA mediocre de uno excelente? Estos son los errores que veo con más frecuencia:

• Hallazgos genéricos: escribir «problemas de contraste» sin especificar dónde, qué elementos ni qué ratio de contraste se encontró.
• Falta de evidencias: no incluir capturas de pantalla, fragmentos de código ni resultados de herramientas como axe DevTools o WAVE.
• Ausencia de impacto en usuario: describir el problema técnico sin explicar cómo afecta a personas reales.
• No indicar la remediación: señalar el error sin proponer solución concreta. Un buen IRA es también una guía de solución.
• Mezclar severidades: tratar todos los hallazgos con la misma urgencia, lo que paraliza al equipo de desarrollo.
• Ignorar hallazgos positivos: un IRA completo también documenta lo que funciona bien, no solo los errores.

Plantilla IRA: estructura recomendada para hallazgos

Si estás creando tu primer IRA o quieres mejorar tu plantilla actual, esta es la estructura que recomiendo basada en la metodología WCAG-EM del W3C:

• 1. Resumen ejecutivo: visión general del estado de accesibilidad con métricas clave.
• 2. Alcance de la evaluación: páginas evaluadas, tecnologías, herramientas utilizadas.
• 3. Metodología: combinación de pruebas automáticas (axe DevTools, WAVE) y manuales.
• 4. Resumen de hallazgos: tabla resumen con conteo por severidad y criterio WCAG.
• 5. Hallazgos detallados: cada hallazgo con la estructura de 9 elementos descrita arriba.
• 6. Hallazgos positivos: elementos que ya cumplen con WCAG 2.1.
• 7. Hoja de ruta de remediación: priorización y calendario de correcciones.
• 8. Anexos: capturas de pantalla, resultados de herramientas, referencias WCAG.