Actualizado: .
La accesibilidad se evalúa con varios métodos: análisis automático, revisión manual y personas realizando tareas. Ninguno sustituye a los demás. La unidad de evaluación debe ser un recorrido completo, incluidos los errores y la recuperación.
Defina primero el alcance
Anote la versión del producto, la versión y el nivel de WCAG previstos, las páginas, los procesos, los idiomas, los estados y los entornos. «Hemos probado el sitio» no aclara si se comprobó el pago tras caducar la sesión o solo la página de inicio. Incluya distintos tipos de páginas, componentes complejos y recorridos críticos.
Nuestro recorrido de trabajo es: encontrar un servicio → abrir su descripción → rellenar una solicitud → corregir un error → enviar → recibir confirmación. Una tienda añade carrito, pago y devoluciones; una cuenta, inicio de sesión y recuperación del acceso. Si un paso obligatorio es inaccesible, los pasos anteriores completados no salvan el resultado.
La automatización detecta rápidamente parte de los defectos
WAVE ayuda a detectar errores y revisar la estructura de la página, pero no es un lector de pantalla ni reproduce exactamente cómo la leerá cada lector. Facilita la evaluación humana. Encontrar cero errores no significa conformidad completa.
Ejecute comprobaciones automáticas sobre estados reales: menú abierto, formulario rellenado, error y diálogo modal. Revisar la pantalla inicial no inspecciona el DOM que solo aparece después de una acción. Conserve los resultados de forma que quede claro qué estados se cubrieron.
Un recorrido manual sin ratón
- Empiece al cargar la página. Compruebe el acceso al contenido principal y un orden de foco lógico.
- Complete la tarea con teclado. Compruebe que todas las acciones están disponibles y que no hay trampas involuntarias.
- Abra y cierre cada componente complejo. Observe dónde se desplaza el foco.
- Provoque un error y corríjalo. Asegúrese de que el valor se conserva y la explicación resulta clara.
- Compruebe la confirmación: la persona debe saber si la acción se ha completado.
Revise también el puntero. El tamaño mínimo de objetivo de 24 × 24 CSS px en WCAG 2.5.8 AA tiene excepciones, incluido un espacio suficiente entre objetivos. 44 × 44 corresponde a otro criterio, más exigente; no es un mínimo universal de AA. Se pueden diseñar objetivos táctiles mayores sin presentar esa decisión como una exigencia literal.
El arrastre debe tener una alternativa con un solo puntero y sin arrastrar, salvo que se aplique una excepción. Por ejemplo, un elemento puede moverse con botones «Subir» y «Bajar». Una alternativa exclusivamente de teclado no cubre a quien usa un puntero, pero no puede mantenerlo pulsado y arrastrar.
Compruebe la percepción y los ajustes personales
Revise el texto al 200%, la redistribución a una anchura equivalente de 320 CSS px, los espaciados definidos por el usuario y los colores forzados. Inspeccione todos los temas, no solo el principal. Busque mensajes de error cortados, etiquetas que desaparecen y superposiciones de paneles fijos.
Las alternativas necesarias dependen del tipo de medio y del nivel de WCAG. Para vídeo pregrabado con audio, compruebe los subtítulos sincronizados y la audiodescripción de la información visual esencial que no figure en la pista de audio. El audio pregrabado sin vídeo generalmente necesita una transcripción. El vídeo sin sonido y las emisiones en directo tienen requisitos propios; una transcripción no sustituye todos los requisitos de medios sincronizados. Planifique un reproductor accesible y las alternativas necesarias antes de producir el vídeo.
Reduzca las animaciones no esenciales en respuesta a prefers-reduced-motion. Compruebe por separado el contenido que se mueve automáticamente, la posibilidad de pausarlo y los destellos: una sola consulta de medios no confirma todos los requisitos relacionados. Las instrucciones sencillas, evitar presiones de tiempo innecesarias y conservar lo introducido tras un error también influyen en la posibilidad de completar la tarea.
Lectores de pantalla y participación de usuarios
Elija combinaciones de navegadores y tecnologías de apoyo según el público, por ejemplo, situaciones de escritorio y móvil. Anote las versiones. Compruebe la estructura, los nombres de elementos, los valores actuales, los estados, los mensajes y el orden de lectura. Una combinación que funciona no demuestra compatibilidad con todas.
Invite a personas con distintas necesidades de acceso a probar tareas reales y remunere su trabajo. No reduzca la investigación a «¿le gusta el sitio?». Observe si pueden completar la acción, dónde necesitan ayuda y si la recuperación de errores se entiende. Los participantes no sustituyen la comprobación de criterios, ni esta sustituye a los participantes.
Cómo es un informe de defecto útil
Situación: enviar una solicitud con un correo incorrecto. Entorno: versiones concretas del sistema operativo, navegador y lector de pantalla. Pasos: rellenar el formulario, introducir una dirección incorrecta y enviar. Resultado real: el borde se vuelve rojo, pero falta una explicación. Consecuencia: no se sabe qué valor cambiar ni cómo corregirlo. Resultado esperado: el error se expresa mediante texto asociado al campo. Nueva comprobación: se percibe el error, la corrección se conserva y se puede enviar la solicitud.
Priorice según el impacto en la finalización de la tarea y la presencia del componente en el producto, no solo por el número de hallazgos. Un paso de pago inaccesible puede importar más que decenas de incidencias decorativas iguales. Sin embargo, el orden de corrección no elimina los criterios necesarios para el nivel de conformidad declarado.
Cómo mantener las mejoras
Incluya en el sistema de diseño los requisitos de cada componente: nombre, rol, estados, teclado, foco, errores y ampliación. Tras los cambios, repita los recorridos afectados. Después de corregir un componente compartido, revise las páginas que lo utilizan además de su demostración aislada.
En el informe final, distinga problemas encontrados, alcance evaluado, limitaciones de la revisión y riesgos pendientes. «No se encontraron incumplimientos de estos criterios en esta muestra de estados» informa mejor que una afirmación sin límites como «el sitio es accesible al 100%».
Para incorporar estas comprobaciones al desarrollo con un asistente de IA, puede obtener el skill Accessible UI en GitHub. El primer artículo incluye instrucciones de instalación para Codex y Claude Code.
A partir de esta investigación, creamos skills abiertos para Codex y Claude Code que ayudan a analizar y mejorar sitios web y aplicaciones. Accessible UI guía la revisión de la semántica, el teclado, el foco, los formularios y el contraste; Adaptive Interfaces ayuda a adaptar la interfaz al tamaño de la ventana, la escala del texto, el teclado y los dispositivos plegables. El agente examina el proyecto real, propone mejoras fundamentadas y verifica los cambios acordados. Estos skills no sustituyen las pruebas con usuarios y tecnologías de asistencia.
Fuentes y estado de los estándares verificados el 5 de noviembre de 2026.