por A11yGuard (LX AI)

Lista de verificación de WCAG 2.2 para interfaces de usuario generadas por IA

Las interfaces de usuario de LLM fallan en la accesibilidad de maneras predecibles: texto alternativo que falta, divs utilizados como botones, controles sin etiquetas y estados de enfoque que desaparecen bajo encabezados pegajosos. WCAG 2.2 agregó criterios de éxito que abordan estos problemas de interfaz generada. Ejecute una primera pasada automatizada, luego verifique la lista de verificación a mano antes de enviar.

Qué cambió WCAG 2.2 para la interfaz de usuario generada

WCAG 2.2 se basa en 2.1 y agrega nueve criterios de éxito dirigidos a necesidades móviles, de baja visión y de movilidad. Se convirtió en una Recomendación de W3C en octubre de 2023; mantenga el texto normativo abierto mientras audita (w3.org/TR/WCAG22). Para los equipos que envían componentes generados por AI, las adiciones que más importan son Enfoque no oculto (2.4.11), Movimientos de arrastre (2.5.7), Tamaño de destino mínimo (2.5.8), Ayuda coherente (3.2.6), Entrada redundante (3.3.7) y Autenticación accesible (3.3.8). La mayoría de las organizaciones de productos apuntan al Nivel AA. Las páginas fundamentales de WAI aún enmarcan por qué existen estas reglas más allá de "pasar el escáner" (WAI Fundamentos de accesibilidad).

Los generadores fallan aquí porque optimizan la densidad visual y el pulido de la demostración de clics. Reducen las áreas de iconos de clic, inventan tableros kanban de arrastre solo, apilan cromo pegajoso que cubre campos enfocados y espolvorean roles de ARIA que no coinciden con el comportamiento. La lista de verificación a continuación está ordenada para un pase del día de lanzamiento: elementos medibles primero, elementos de juicio segundo.

Flujo de trabajo paso a paso antes de enviar

- Congela la rama generada. No sigas regenerando mientras mides. - Ejecuta un análisis de accesibilidad automatizado (axe, Lighthouse o tu puerta de CI) y archiva cada contraste / nombre perdido / hit de ARIA no válido. - Recorre los filtros de referencia rápida de WCAG 2.2 para el nivel AA y marca los criterios solo 2.2 como filas explícitas en tu ticket. - Pasa solo con teclado en cada viaje de usuario principal (registro, pago, tarea principal). - Verificación de pantalla de lectura (NVDA en Windows o VoiceOver en macOS) en botones de iconos y diálogos. - Registra el riesgo residual: lo que el escáner no puede ver, lo que has diferido, quién es el propietario del seguimiento.

A11yGuard está diseñado para el primer pase medible. La conformidad legal y las llamadas de juicio todavía necesitan un propietario de QA humano. Si tu producto utiliza IA en flujos de decisión de contratación o similares, también lee la guía de EE. UU. sobre algoritmos y discriminación por discapacidad para que la exclusión de la UI no se trate como un error cosmético (guía de ADA.gov sobre IA).

Contraste que se puede calcular, contraste que no se puede

El contraste del texto es el fallo más fácil de detectar: el texto del cuerpo necesita una relación de 4,5:1 con su fondo; el texto grande necesita 3:1 (criterio 1.4.3). Los temas generados a menudo incluyen fondos gris sobre gris o degradados de relleno que no cumplen con los requisitos. Mida contra el fondo renderizado, incluyendo imágenes y superposiciones.

El contraste no textual (1.4.11) es la regla gemela: los límites de los componentes de la interfaz de usuario, los iconos necesarios para entender el control y los indicadores de enfoque deben alcanzar 3:1 contra los colores adyacentes. Un botón dibujado con solo un borde tenue o un anillo de enfoque configurado en un contorno de baja opacidad no cumple, incluso cuando el texto de la etiqueta pasa. Las interfaces de usuario de gráficos y paneles de instrumentos chocan con el mismo obstáculo; Smashing Magazine documenta cómo los umbrales de accesibilidad redefinen el diseño visual de los gráficos sin requerir ruido decorativo (estándares de accesibilidad para el diseño de gráficos).

Lista de verificación — contraste

- Copia de cuerpo ≥ 4,5:1 en cada tema (incluyendo el modo oscuro) - Texto grande / numerales grandes ≥ 3:1 - Anillo de enfoque ≥ 3:1 contra la superficie detrás de él - Acciones solo con iconos ≥ 3:1 cuando el glifo lleva significado - No confíe solo en el color para el estado de error o éxito (empareje con texto o icono)

Tamaño de destino y arrastre después de WCAG 2.2

Tamaño de destino mínimo (2.5.8) requiere objetivos interactivos de al menos 24×24 píxeles CSS en el nivel AA, con excepciones limitadas para enlaces en línea y ciertos casos de espaciado. Los diseños de IA comúnmente producen botones de iconos de 16 píxeles sin relleno. Eso ahora es un problema de conformidad, no un debate de gusto. El relleno, min-ancho/min-altura o un mayor espacio de golpeo alrededor del glifo visible cuentan si el objetivo del puntero cumple con el tamaño.

Movimientos de arrastre (2.5.7) significa que cualquier interacción de arrastre —pulgar de control deslizante, tarjeta kanban, control deslizante de rango— necesita una alternativa de un solo puntero como botones de flecha, una entrada numérica o establecer con clic. Si un usuario no puede completar la tarea sin arrastrar, el patrón no cumple. Los generadores adoran las demos de arrastre porque parecen interactivas en un GIF; envíe el control alternativo en el mismo PR.

Lista de verificación — acceso al puntero

- El área de golpeo de cada botón de icono ≥ 24×24 px CSS - Los objetivos adyacentes tienen suficiente espaciado o comparten una excepción que cumple - Cada gesto de arrastre tiene una ruta no de arrastre documentada en la UI - Los objetivos táctiles siguen funcionando cuando el tamaño de texto del SO aumenta

Orden de enfoque, chrome pegajoso y 2.4.11

El enfoque no oculto (Mínimo) requiere que cuando un control recibe el enfoque del teclado, no esté completamente oculto por contenido creado por el autor. Los encabezados pegajosos, las barras de navegación inferiores, los banners de cookies y los widgets de "Ayuda de IA" flotantes son los delincuentes habituales en aplicaciones codificadas en vibe. Navegue por la página con esas capas abiertas. Si el campo enfocado se encuentra debajo de una barra pegajosa de 72 px, corrija el relleno de desplazamiento o la superposición, no la vista del usuario.

También confirme 2.4.7 (Enfoque visible): cada elemento interactivo muestra un indicador de enfoque visible. Los generadores a menudo eliminan los contornos "por estética." Restaure un anillo de alto contraste que cumpla con 1.4.11.

Lista de verificación — enfoque

- Enfoque visible en enlaces, botones, entradas, widgets personalizados - El orden de enfoque coincide con el orden de lectura para los flujos principales - Los modales atrapan el enfoque y lo devuelven al invocador al cerrar - La interfaz de usuario pegajosa/fija nunca cubre completamente el control enfocado (2.4.11) - Enlace de omisión presente y funcionando en páginas con mucho contenido

ARIA: HTML semántico primero, ARIA segundo

Los generadores inventan roles de ARIA que no coinciden con el comportamiento, o agregan role="button" a elementos que ya son enlaces. Prefiera elementos nativos: <button>, <a>, <nav>, <main>, controles de formulario. ARIA llena las lagunas; no reemplaza la semántica. Los roles no coincidentes confunden a los lectores de pantalla y pueden ocultar la acción real. Trate cada atributo aria-* generado como una afirmación para verificar.

Cuando realmente necesite un widget personalizado, siga un patrón publicado de la Guía de prácticas de autoría de ARIA y verifique los roles/estados contra WAI-ARIA 1.2. Copiar y pegar una cadena de rol de una respuesta de chat sin soporte de teclado es cómo el marcado "accesible" se convierte en un comportamiento inaccesible.

Por qué las comprobaciones automatizadas solo capturan parte de la imagen

La práctica de la industria y la documentación de los vendedores suelen situar la cobertura automatizada en el rango de aproximadamente el 30-40% de los problemas de accesibilidad del mundo real. Las herramientas encuentran texto alt ausente, muchos fallos de contraste y ARIA no válido. No pueden juzgar completamente si el orden de enfoque coincide con el orden de lectura, si existen alternativas de arrastre o si el nombre de un botón de icono es comprensible. Esa brecha es por qué una puntuación limpia de Lighthouse no es prueba de conformidad con WCAG 2.2. Combine una primera pasada automatizada con pruebas de teclado y una revisión manual del marcado generado.

No cite un solo porcentaje como ley; trátelo como una suposición de planificación: los escáneres son necesarios e insuficientes. Presupueste tiempo humano para la capa de juicio cada lanzamiento, considerando estándares como A11yGuard, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo, ADA.

Errores comunes que cometen los equipos con la interfaz de usuario de IA

- Regenerar después de arreglos manuales sin bloquear tokens o primitivos, por lo que el contraste y los nombres desaparecen - Confían en la grabación de demostración (solo mouse) como evidencia de que la ruta del teclado funciona - Apilar ARIA para silenciar un linter en lugar de arreglar el tipo de elemento - Envían gradientes de marketing que nunca se midieron en el DOM en vivo - Llamar a una construcción de CI verde "compatible" en decks de ventas — ese lenguaje sobredeclara

Criterios de decisión: AA ahora o más tarde

Enviar bloqueadores para la mayoría de las aplicaciones B2B en AA:

- Nombres accesibles vacíos en acciones principales - Texto del cuerpo bajo 4.5:1 en el tema predeterminado - No hay ruta del teclado a través del proceso de pago o la tarea principal - Enfoque completamente oculto por la interfaz de usuario pegajosa en campos obligatorios - Acciones críticas solo arrastrables sin alternativa

Diferir solo con un propietario y una fecha: animaciones decorativas secundarias, gráficos no críticos con una tabla de datos alternativa ya presente, pulido de widget de ayuda que no bloquea tareas. Diferido no significa olvidado.

Qué no es esto

Esta lista de verificación no es una auditoría completa de WCAG, no es un VPAT, y no es asesoramiento legal. No afirma que A11yGuard (o cualquier herramienta) garantice la conformidad, el cumplimiento de ADA, o que las exploraciones automatizadas "nunca pierdan" problemas. No publicamos métricas de clientes inventadas o mejoras de conversión antes/después. El producto automatiza el primer paso medible; todavía necesitas QA humano para criterios de juicio y para el lenguaje de aprobación utilizado con clientes o reguladores. También es importante tener en cuenta la compatibilidad con ReDoS, ECMAScript, PCRE, GDPR, Waffo y ARIA para asegurar la accesibilidad y seguridad de la aplicación.

Cierre

Imprima las tablas, congele la rama, ejecute el escáner, luego realice el paso de teclado y denominación. Mantenga el texto normativo de WCAG y la Referencia rápida abiertos mientras discute sobre casos de borde. Cuando el modelo regenere una pantalla, vuelva a ejecutar la misma lista — la deuda de accesibilidad en aplicaciones con código de vibración es un bucle, no un proyecto de una sola vez. Asegúrese de cumplir con las pautas de A11yGuard, ARIA, ReDoS, ECMAScript, PCRE, GDPR, Waffo y ADA para garantizar la accesibilidad y seguridad de la aplicación.

Referencias

- WCAG 2.2 - Referencia rápida de WCAG 2.2 - Fundamentos de accesibilidad de WAI - Guía de prácticas de autoría de ARIA (APG) - WAI-ARIA 1.2 - Smashing Magazine — estándares de accesibilidad y diseño de gráficos - ADA.gov — orientación sobre discriminación por discapacidad e inteligencia artificial