Accesibilidad de verdad: el agente audita, la persona confirma
Un agente barre WCAG en minutos, contraste, texto alternativo, orden de foco, rol ARIA, cubriendo a escala lo que un checklist manual tomaría días. Solo que aprobado técnico no es experiencia real: carga cognitiva, orden de lectura y confusión de etiqueta solo la persona las siente. Accesibilidad de verdad es la suma de los dos.
Una municipalidad manda inspeccionar la rampa de acceso de un edificio público. El inspector llega, mide la inclinación con el instrumento correcto, verifica el ancho mínimo, revisa el pasamanos, todo dentro de la norma técnica. Sella aprobado. Solo que nadie empujó una silla de ruedas real por esa rampa: el piso es demasiado resbaloso cuando llueve, la puerta en la parte superior es pesada y no tiene barra de apoyo, y una persona en silla de ruedas real no puede abrirla sola después de subir. La rampa pasó la medición. La experiencia real de quien la necesita sigue siendo imposible.
Un sistema de conciliación bancaria revisa automáticamente todas las transacciones del mes y las marca "conciliadas", porque cada asiento coincidió con un registro correspondiente. Pasa la regla técnica. Solo que un auditor humano, mirando los valores con atención, nota que tres transacciones "conciliadas" se emparejaron con el registro equivocado, valores parecidos pero de cuentas diferentes, algo que la regla automática no tenía cómo percibir porque solo verifica si existe un par, no si el par tiene sentido de negocio.
Una herramienta de revisión de contrato verifica, cláusula por cláusula, si cada una coincide con la plantilla estándar del despacho. Todas pasan la verificación individual. Solo que un abogado leyendo el contrato entero, de principio a fin, nota que la cláusula 4.2 de rescisión, sola correcta, contradice la cláusula 9 de multa cuando se leen juntas, un problema que solo aparece en la lectura continua, no en la verificación aislada de cada cláusula.
Un verificador automático de marca revisa si toda pieza de una campaña usa el color correcto, la fuente correcta, el logo del tamaño correcto. Cien por ciento de conformidad técnica. Solo que un revisor humano, leyendo la pieza como la va a leer el cliente, nota que la frase de apertura suena condescendiente para el público de esa región, algo que ninguna verificación de color o fuente jamás captaría, porque es sobre tono, no sobre forma.
Un sistema de selección automática aprueba a un candidato porque el currículum coincide con las palabras clave de la vacante: las certificaciones correctas, los años de experiencia correctos. Pasa el filtro. Solo que el entrevistador humano, en la conversación, nota que el candidato nunca lideró un equipo en crisis de verdad, solo lo documentó en el papel, una diferencia que ninguna palabra clave captaría, porque exige juicio humano sobre la experiencia real detrás del texto.
Una suite de pruebas automatizadas corre antes de cada deploy y aprueba el build entero, todas las pruebas en verde. Pasa la regla técnica. Solo que en una prueba con usuario real, una persona se traba en el segundo paso del onboarding porque no entiende qué va a hacer el botón "continuar", un problema que ninguna prueba automatizada detectaría, porque esa prueba verifica si el código funciona, no si la persona entiende lo que está en pantalla.
Un CRM valida automáticamente que un negocio está listo para avanzar de fase, todos los campos obligatorios completos, checklist en verde. Pasa la regla del sistema. Solo que el vendedor, en la llamada real, siente que el cliente está dudoso y el negocio corre riesgo real de enfriarse, algo que ningún campo de formulario captaría, porque es lectura humana de tono de voz y duda, no dato estructurado.
Un panel de SLA muestra la atención de nivel 2 dentro de la meta, cien por ciento verde en el mes. Aprobado en el panel. Solo que un agente de primera línea sabe que, en un tipo específico de ticket, el equipo siempre estira el plazo hasta el límite y lo disfraza en el informe, un problema que el panel de promedio mensual no revela, porque mide el agregado, no el caso específico que casi siempre falla.
Un checklist automático verifica si la política de privacidad cita todos los ítems exigidos por la LGPD, y los cita, ítem por ítem. Aprobado técnicamente. Solo que un revisor humano, leyendo el flujo de consentimiento como el usuario realmente lo vive, nota que el botón de aceptar es grande y destacado mientras el de rechazar es un enlace gris casi invisible, una práctica que pasa la verificación de texto y falla por completo el espíritu de la ley.
Un pipeline de CI corre la suite de pruebas unitarias y de integración antes del merge, todo en verde, cobertura de código por encima de la meta. Aprobado técnicamente. Solo que en producción, bajo carga real, un ingeniero humano descubre que una race condition rara tumba el servicio una vez por semana, algo que ninguna prueba automatizada captó porque la condición solo aparece en la concurrencia real de usuarios, no en el entorno controlado de la prueba.
Corres un escáner de accesibilidad en el flujo de checkout de tu producto y aprueba en minutos: contraste dentro del mínimo exigido, toda imagen con texto alternativo, orden de foco en el teclado sin fisuras, roles ARIA presentes donde deberían estar. Cien por ciento verde en la regla técnica. Solo que cuando tú mismo navegas ese mismo flujo con los ojos cerrados, usando un lector de pantalla real, descubres que el botón "Finalizar" se lee antes del resumen del pedido, así que quien usa el lector de pantalla escucha "finalizar" sin saber todavía qué está finalizando. Técnicamente, cada elemento pasó la verificación aislada. En la experiencia real de quien depende del lector de pantalla para comprar, el flujo entero no tiene sentido.
Un panel de OKR muestra todos los indicadores del trimestre en verde, cada meta numérica cumplida dentro del plazo. Aprobado en el panel. Solo que un ejecutivo revisando el plan con calma nota que las metas verdes no tocan de hecho la amenaza competitiva que motivó el plan, el equipo cumplió el número, pero el problema real que el directorio quería resolver sigue en pie, invisible para el panel que solo mide lo que se definió como métrica.
Oye, déjame contarte la escena que más engaña a la gente buena en esta trilla. Corres un escáner de accesibilidad en tu checkout, devuelve todo en verde, contraste bien, texto alternativo bien, foco bien, ARIA bien, y respiras aliviado creyendo que lo resolviste. Solo que cuando tú mismo navegas ese flujo con un lector de pantalla real, sin hacer trampa usando el mouse, descubres que el orden de lectura no tiene ningún sentido: el botón de finalizar se lee antes del resumen del pedido. Aprobado técnico e inutilizable en la práctica, al mismo tiempo, en el mismo flujo. Esta lección trata sobre entender por qué pasa esto, y sobre la regla correcta para no caer en esa trampa.
La idea central de esta lección. Un agente de IA puede auditar WCAG (contraste de color, texto alternativo en imagen, orden de foco en el teclado, rol ARIA) a escala y en minutos, cubriendo lo que un checklist manual tomaría días en revisar en todo el producto. Eso resuelve la conformidad técnica. No resuelve, solo, la experiencia real de quien usa lector de pantalla, navega solo por teclado o tiene baja visión: carga cognitiva, orden de lectura que tiene sentido, una etiqueta que técnicamente pasa el contraste pero confunde en la práctica, son cosas que el agente no siente, solo la persona las siente. La regla de esta lección es simple de enunciar: el agente hace el barrido amplio y cubre el volumen que nadie tiene tiempo de verificar manualmente en todo; la persona, idealmente alguien que de hecho usa tecnología asistiva, o una prueba guiada por heurística humana, confirma lo que importa de verdad en la experiencia. Accesibilidad de verdad es la suma de los dos. Nunca solo el barrido automático, que puede dar aprobado en una pantalla que sigue siendo inutilizable.
01Lo que el agente resuelve rápido: el barrido a escala
Empecemos por lo que la IA hace genuinamente bien, y es bastante. Un agente con acceso a tu producto puede correr, en minutos, una auditoría contra la regla técnica objetiva de la accesibilidad, el WCAG 2.2, el estándar del W3C que define criterios medibles: si el contraste entre texto y fondo está por encima del mínimo, si toda imagen tiene un texto alternativo describiendo lo que muestra, si el orden de foco al navegar por teclado sigue una secuencia lógica, si los elementos interactivos tienen el rol ARIA correcto para que la tecnología asistiva entienda qué son.
Eso es volumen que un checklist manual no logra cubrir en todo el producto, toda pantalla, todo componente, cada vez que algo cambia. Un agente hace ese barrido de nuevo con cada cambio, sin cansarse y sin saltarse ninguna pantalla. Es exactamente el tipo de trabajo mecánico y repetitivo que vale la pena quitarle a la mano humana, para que sobre tiempo para lo que solo la mano humana puede evaluar.
02Lo que solo la persona siente: carga cognitiva, orden que tiene sentido, confusión real
Ahora el otro lado, que es donde vive la trampa. Un elemento puede pasar todos los criterios técnicos, aisladamente, y el flujo entero seguir sin tener sentido para quien usa tecnología asistiva. El caso del ejemplo que abrió la lección es exactamente ese: cada elemento del checkout, solo, coincidía con el WCAG. El botón tenía el contraste correcto. La imagen tenía texto alternativo. El rol ARIA estaba presente. Solo que el orden en que el lector de pantalla leía esos elementos no seguía la lógica de lo que una persona necesita saber antes de decidir: escuchar "finalizar" antes de escuchar qué se está finalizando rompe la experiencia entera, incluso con todos los criterios técnicos aprobados uno por uno.
Esto pasa porque existen dimensiones de accesibilidad que no se resumen a una regla binaria de pasa o no pasa. Carga cognitiva, es fácil entender lo que esta pantalla me pide, o necesito releerla tres veces. Orden de lectura, lo que viene primero tiene sentido para la decisión que necesito tomar. Claridad de etiqueta, "haz clic aquí" técnicamente tiene buen contraste, pero no dice nada sobre lo que va a pasar cuando haga clic. Ninguna de estas tres cosas se mide con una herramienta automática, porque no son propiedades del código, son propiedades de la experiencia vivida por una persona navegando ese flujo de una forma específica. Solo quien de hecho depende del lector de pantalla, o navega todo el día solo con teclado, siente ese tipo de fricción en carne propia.
03La regla de la lección: el agente cubre el volumen, la persona confirma la experiencia
Llegamos a la división de trabajo que resuelve el problema sin descartar ninguno de los dos lados. El agente entra primero, y hace el barrido amplio: todo el producto, todo componente, contra la regla objetiva del WCAG 2.2. Eso ya elimina una cantidad grande de problema real, porque mucha barrera de accesibilidad es, sí, técnica y mecánica, mal contraste, imagen sin descripción, elemento sin rol ARIA, cosas que el barrido detecta directo y que representan buena parte de los problemas más comunes en la web hoy.
Solo que la literatura del sector es honesta sobre el límite: menos de la mitad de los problemas reales de accesibilidad suele ser detectable solo con herramienta automática, el resto exige evaluación humana, con juicio sobre experiencia de uso. Por eso la regla correcta no es elegir entre agente o persona, es usar los dos en secuencia: el agente barre todo, rápido y barato, cubriendo el volumen que ningún equipo tendría tiempo de revisar manualmente en cada pantalla. La persona, después, prueba el flujo de verdad, de preferencia alguien que usa tecnología asistiva a diario, o al menos una prueba guiada por heurística humana (navegar solo con teclado, escuchar el flujo entero con el lector de pantalla activado, sin hacer trampa mirando la pantalla). Lo que la persona encuentra ahí es exactamente lo que el agente, por naturaleza, no puede sentir.
Por qué "aprobado técnico" no es sinónimo de accesible
Vale la pena entender la raíz del problema para no caer de nuevo en él en otro contexto. El WCAG 2.2 está escrito como un conjunto de criterios de éxito, cada uno pensado para ser verificable, contraste mínimo de 4,5 a 1, presencia de texto alternativo, y eso es una virtud del estándar, porque permite auditoría objetiva a escala. Pero verificable no es lo mismo que suficiente. Un criterio aislado puede pasar y la combinación de los criterios, en el orden en que la persona realmente encuentra los elementos, seguir fallando. Es el mismo razonamiento de cualquier sistema de reglas: puedes cumplir cada regla individual y aun así producir un resultado que nadie quería, porque la regla no captó la intención detrás de ella. El informe anual de WebAIM, que barre millones de páginas reales, encuentra año tras año una cantidad enorme de errores técnicos básicos todavía presentes en la web más usada, lo que muestra que ni siquiera la parte fácil, la auditoría automática, se está haciendo en la mayoría de los productos. Es decir: antes de discutir si la auditoría automática es suficiente, la mayor parte del mercado todavía ni la está corriendo. Haz las dos etapas, en el orden correcto, y ya estarás por delante de la mayoría.
Ahora construye
Elige un flujo real de tu tarea real, de preferencia uno que involucre decisión del usuario, un checkout, un registro, una etapa de aprobación. Haz las dos etapas, en secuencia, sin saltarte ninguna.
ETAPA 1 · EL AGENTE BARRE
- Pídele a una IA con acceso a tu producto (o pega el HTML de la pantalla) que audite ese flujo contra el WCAG 2.2: contraste, texto alternativo, orden de foco, rol ARIA.
- Enumera los problemas que encontró, uno por uno, con el criterio técnico que cada uno viola.
ETAPA 2 · LA PERSONA CONFIRMA
- Ahora navega ese MISMO flujo tú mismo, solo con teclado, sin tocar el mouse, de principio a fin. Anota dónde te trabaste, dónde el foco saltó a un lugar que no tenía sentido, dónde ya no sabías en qué campo estabas.
- Si puedes, activa el lector de pantalla nativo de tu sistema (VoiceOver en Mac, Narrador en Windows) y escucha el flujo entero con los ojos cerrados. Anota lo que sonó confuso, fuera de orden, o incompleto, aunque la herramienta automática haya aprobado ese mismo fragmento.
Compara las dos listas. La primera es tu deuda técnica resuelta rápido. La segunda es lo que solo apareció porque una persona, no una herramienta, vivió el flujo de verdad. Si la segunda lista tiene algún ítem que la primera no detectó, acabas de confirmar, en la práctica, por qué la accesibilidad de verdad nunca es solo el barrido automático.
Practica
1. Un escáner de accesibilidad aprueba el checkout con contraste, texto alternativo, foco y ARIA todos correctos, pero un usuario de lector de pantalla no puede completar la compra. ¿Qué revela esto?
2. ¿Cuál es el papel correcto del WCAG 2.2 en esta división de trabajo entre agente y persona?
3. ¿Por qué la carga cognitiva y el orden de lectura que tiene sentido son difíciles de auditar solo con herramienta automática?
4. ¿Cuál es la regla correcta de esta lección para dividir el trabajo de accesibilidad entre agente de IA y persona?
¿Listo? Cerremos juntos el mensaje de esta lección. Un agente con acceso a tu producto audita WCAG 2.2 a escala, contraste, texto alternativo, orden de foco, rol ARIA, en minutos, cubriendo el volumen que un checklist manual nunca lograría revisar en todas partes. Eso resuelve la conformidad técnica, y la resuelve rápido. Pero carga cognitiva, orden de lectura que tiene sentido y claridad de etiqueta son cosas que solo una persona navegando el flujo de verdad puede sentir, y ningún barrido automático sustituye eso. La regla que queda: el agente cubre el volumen, la persona confirma la experiencia. Accesibilidad de verdad es la suma de los dos, nunca la mitad haciéndose pasar por el todo. Siguiente.
Para la pizarra
Sobre el verde del escánercada elemento puede pasar solo y la secuencia entera todavía confundir a quien depende del lector de pantalla.
Sobre la divisiónel agente cubre el volumen técnico. La persona confirma la experiencia vivida.
Sobre lo que no se mideel contraste se vuelve número. La carga cognitiva y un orden que tiene sentido dependen de que alguien viva el flujo.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.