Auditar la accesibilidad de un recorrido web

GUÍA / PROTOCOLO

Auditar la accesibilidad de un recorrido web

La accesibilidad se evalúa en una tarea completa: encontrar, comprender, actuar y recuperarse de un error.

Respuesta directa

¿Cómo realizar una auditoría de accesibilidad útil?

Seleccione recorridos y estados críticos. Combine inspección del código, navegación por teclado y tecnologías de apoyo. Vincule cada defecto con una tarea bloqueada, un requisito WCAG, pruebas y una nueva comprobación.

01 / Método de control

Método de control

01

Elegir recorridos

Incluya entrada, navegación, formulario, confirmación y error. Pruebe móvil y zoom elevado.

02

Usar el teclado

Revise orden y visibilidad del foco, controles, menús, diálogos y salida de componentes. Detecte bloqueos.

03

Comprobar el significado

Revise títulos, nombres accesibles, etiquetas, alternativas de imágenes, estructura, contraste y avisos de error con lector de pantalla.

04

Priorizar y repetir

Clasifique por tarea y gravedad, corrija componentes compartidos y repita el recorrido y otras páginas afectadas.

02 / Pruebas que conservar

Pruebas que conservar

Escenario y entorno

URL, dispositivo, navegador, tecnología de apoyo, zoom y acción intentada.

Reproducción

Pasos exactos, captura o DOM y resultados observado y esperado.

Criterio e impacto

Criterio WCAG, personas o tareas afectadas y gravedad razonada.

Nueva prueba

Corrección, versión, fecha y resultado con teclado y lector.

TRAS LA REVISIÓN

Decidir según el hallazgo

01

El menú se ve pero no funciona con teclado

Detenga la aprobación, corrija el componente común y pruebe apertura, navegación y cierre en sus páginas.

02

Pasa el control automático pero la instrucción no se entiende

Conserve el resultado, documente la tarea fallida y reescriba la instrucción antes de repetir la prueba.

03 / FAQ

Preguntas frecuentes

¿Basta una herramienta automática?

No. Detecta ciertos errores de código, pero no siempre el orden lógico o la realización de una tarea.

¿Qué probar primero?

Componentes comunes y recorridos esenciales como navegación, búsqueda, solicitud o contacto.

¿Hay que probar cada idioma?

Sí en las pantallas clave: idioma declarado, etiquetas, errores y orden de lectura varían.

¿Cuándo cerrar un fallo?

Cuando el escenario original funciona con los modos de acceso pertinentes sin romper otros estados.

Describir un contexto