Accesibilidad web con IA: probar el recorrido completo

La pregunta es si la persona puede terminar su tarea

Una empresa puede recibir un informe de accesibilidad con pocos errores y aun tener clientes que no logran enviar una cotización. La revisión útil sigue lo que la persona necesita hacer: encontrar el formulario, entender los campos, corregir un dato y reconocer la confirmación. Para un portal empresarial chileno, ese recorrido permite conversar sobre calidad con el proveedor sin depender únicamente de una puntuación.

Esta guía propone organizar la evaluación en torno a esas tareas. La IA puede apoyar la preparación de pruebas y la explicación de hallazgos; la aceptación de una entrega necesita resultados observados. Conviene acordar desde el inicio qué recorrido se revisará, quién lo evaluará y qué evidencia quedará disponible para una nueva comprobación.

Una metodología internacional que ayuda a ordenar el alcance

WCAG-EM 2.0 fue publicada como Group Note el 23 de julio de 2026. Es una guía de evaluación que aborda alcance, exploración del producto, selección de muestras, evaluación e informe. No añade requisitos a WCAG ni sustituye sus criterios. La citamos como referencia metodológica publicada en julio, no como noticia de hoy. W3C, WCAG-EM 2.0.

La metodología incluye procesos completos y sus variantes críticas: por ejemplo, las vistas y estados necesarios para completar una operación. También advierte que evaluar una muestra de páginas no permite, por sí solo, afirmar conformidad de todo el sitio. Para contratar una revisión, esa diferencia importa: el informe debe permitir reconocer exactamente qué fue examinado y qué quedó fuera.

Dónde puede ayudar la IA al equipo

El 21 de septiembre de 2026, Deque describió pruebas guiadas con IA que presentan lo evaluado, sus conclusiones y el razonamiento para que el desarrollador confirme o corrija los hallazgos. Es la descripción de una capacidad de su producto, no una medición independiente de todos los sistemas de IA. Deque, automatización inteligente y pruebas guiadas.

Proponemos usar un asistente para convertir la descripción de una tarea en un primer guion de pruebas: pasos, estados posibles y dudas para el evaluador. Otro uso acotado es redactar explicaciones de errores para personas de negocio a partir de evidencia técnica ya obtenida. El equipo debe contrastar esas propuestas con el comportamiento del producto y con los criterios que haya acordado evaluar.

Una instrucción de trabajo podría ser: prepara casos para solicitar una cotización y corregir un correo inválido; separa las comprobaciones automáticas de las que necesitan observación humana. La respuesta sería un borrador para revisar. Pedir al modelo que declare accesible todo el portal a partir de capturas o código parcial dejaría sin comprobar interacciones y estados que no recibió. Conviene trabajar con datos ficticios y evitar incluir documentos privados de clientes.

Automatizar comprobaciones en estados concretos

La documentación de Playwright muestra cómo incorporar el motor axe a pruebas del navegador para detectar ciertos problemas de accesibilidad, incluidos controles sin etiquetas identificables y algunos problemas de contraste. También muestra el análisis de contenido después de abrirlo. Recomienda combinar automatización, evaluación manual y pruebas inclusivas con usuarios, porque muchas barreras requieren revisión humana. Playwright, pruebas de accesibilidad.

Aplicado a un portal, sugerimos guardar comprobaciones del formulario inicial, del mensaje de error y de la confirmación. Si el equipo escanea únicamente la primera pantalla, los estados posteriores siguen pendientes. Cada resultado debería indicar la versión revisada y el estado alcanzado; así una modificación futura puede volver a probar el mismo punto. Una prueba que pasó describe sus comprobaciones, no todas las experiencias posibles de uso.

Ejemplo: una cotización que se interrumpe al corregir un campo

Imaginemos un distribuidor chileno con un formulario para solicitar repuestos. Es un ejemplo hipotético. La persona completa sus datos usando el teclado y escribe mal el correo. Aparece una advertencia roja, pero no resulta claro qué campo debe corregir ni cómo volver a él. El equipo comercial podría no advertir esa dificultad mirando solamente las solicitudes que sí llegaron; necesitaría observar también los intentos interrumpidos.

Para aceptar el arreglo, proponemos repetir la tarea con teclado y lector de pantalla, comprobando que se identifica el campo, se entiende la corrección y se puede continuar hasta la confirmación. También conviene ensayar la operación con texto ampliado. La guía inicial de WAI incluye comprobaciones de teclado, foco, ampliación y formularios; advierte que son una primera revisión y no una evaluación exhaustiva. W3C WAI, Easy Checks.

Pedir evidencia útil y mantener el seguimiento

Como acuerdo de entrega, sugerimos un registro breve por barrera: tarea afectada, pasos para reproducirla, comportamiento observado, corrección propuesta y resultado de la nueva prueba. Dejar el responsable y la versión permite distinguir un problema corregido de uno todavía pendiente. Si interviene un componente externo, como autenticación o pago, conviene identificar al responsable de resolverlo y comprobar la continuidad del recorrido.

Para comenzar, elijan una tarea comercial importante y revisen dónde se interrumpe, con participación de personas que utilicen distintas formas de interacción. El objetivo inicial puede ser cerrar barreras comprobadas y conservar pruebas repetibles. Evaluar una tarea ayuda a priorizar trabajo; no transforma ese alcance acotado en una certificación general.

Al contratar desarrollo de software a medida, estos criterios pueden formar parte de la aceptación de la entrega. La guía sobre revisión de código con IA y correcciones verificadas complementa el proceso técnico. Para negocio, la evidencia más útil sigue siendo poder explicar qué dificultad encontraba la persona y cómo se comprobó que puede continuar su tarea.