por A11yGuard (LX AI)

Contraste y ARIA en aplicaciones con código de vibración

Las interfaces de usuario codificadas con vibración fallan en la accesibilidad en dos puntos que los escáneres rara vez capturan juntos: las matemáticas del contraste y los nombres accesibles. Un componente puede aprobar una auditoría de color y aún ser inutilizable cuando su función es incorrecta o su nombre está vacío. Ambos se rompen nuevamente en la regeneración, por lo que la solución pertenece a una lista de verificación, no a una edición única.

Cómo la matemática del contraste se rompe en realidad en temas generados

Cuando un modelo inventa una paleta, generalmente copia una tabla de colores: texto de pizarra suave, chips pastel, tarjetas translúcidas. Eso se ve bien en la pantalla de un diseñador y falla en las proporciones en WCAG 2.2 en el momento en que llega el contenido real. El texto del cuerpo en Nivel AA necesita una proporción de contraste de 4,5: 1 contra su fondo (criterio de éxito 1.4.3). El texto grande puede usar 3: 1. Los generadores no ejecutan esa matemática; eligen valores hex que "se sienten secundarios."

Un segundo modo de fallo es el fondo que no se puede ver en la exportación de Figma. El texto sobre una imagen de héroe, un lavado de gradiente o un panel de glassmorphism necesita el fondo renderizado, no el token con nombre bg-surface. Muestre el píxel debajo del glifo o habilitará una auditoría de token y aún así enviará una copia ilegible. Los gráficos y la tinta de datos tienen la misma trampa; la publicación de Smashing Magazine sobre el contraste de gráficos muestra cómo los umbrales estándar cambian las opciones de diseño visual sin convertir cada gráfico en un arcoíris (estándares de accesibilidad para el diseño de gráficos).

El contraste no textual es el gemelo silencioso

El criterio de éxito 1.4.11 (Contraste no textual) solicita 3: 1 en los límites de los componentes de la interfaz de usuario, objetos gráficos necesarios para entender el contenido y estados como indicadores de enfoque. Un borde de 1 píxel tenue que se ve "premium" a menudo falla. Un anillo de enfoque configurado en outline: 2px solid rgba (15,118,110,.35) falla incluso cuando el texto de la etiqueta pasa 4,5: 1. Los controles de solo icono que dependen de un glifo gris claro contra blanco son el mismo tipo de error. Trate los colores de borde, icono y enfoque como tokens de primera clase con proporciones publicadas, no como adornos posteriores. La referencia rápida de WCAG 2.2 es el lugar más rápido para volver a verificar qué criterios se aplican en AA.

Los tokens superan los parches hexadecimales de una sola vez

La solución duradera es aburrida: defina tokens de color semánticos (texto-primario, texto-atenuado, borde-fuerte, anillo-de-enfoque) con proporciones medidas contra cada fondo permitido, luego prohíba que el modelo invente cadenas hex en archivos de componentes. Coloque la regla de prohibición en el prompt y en CI. Si la regeneración puede reescribir el color: #94a3b8 en una etiqueta de botón, su "solución" nunca fue una solución. Empareje tokens con una capa de variable CSS para que el modo oscuro y los temas de marketing hereden las mismas restricciones.

Los nombres accesibles no son etiquetas visibles

Los lectores de pantalla anuncian el nombre accesible de un control, no los datos de la ruta SVG. Un botón de icono que muestra un glifo de basura sin contenido de texto, sin aria-etiqueta y sin etiqueta asociada se convierte en "botón" sin propósito. Ese es un fallo de denominación, no un fallo de contraste, por lo que las auditorías de color permanecen verdes mientras que los usuarios del teclado se estancan.

El orden de cálculo del nombre se define por el árbol de accesibilidad: texto de contenido, referencias etiquetadas por, luego etiquetas suministradas por el autor como aria-etiqueta. Los generadores a menudo emiten el glifo y una clase Tailwind y se detienen. También inventan nombres duplicados ("Cerrar" en cada control de descarte en una pila de modales) o nombres que describen la metáfora del icono en lugar de la acción ("basura" en lugar de "Eliminar factura"). Prefiera el lenguaje de acción que coincide con la affordance visible.

Donde los nombres desaparecen después de la regeneración

La regeneración borra los valores aria-etiqueta en línea que se agregaron a mano porque el modelo los trata como ruido opcional. Sobreviva a eso:

- Manteniendo mapas de iconos en un módulo que siempre empareja glifo + cadena de nombre - Usando texto visible junto a iconos cuando el espacio lo permite (el nombre viene de forma gratuita) - Hacer que la CI falle cuando un elemento interactivo tiene un nombre accesible vacío - Rechazar las PR que introducen <div onClick> sin un paquete de rol y nombre

La visión general de los fundamentos de WAI sigue siendo el mejor manual breve sobre por qué los nombres, roles y estados deben viajar juntos (WAI Fundamentos de accesibilidad).

Cuándo ARIA ayuda y cuándo oculta el error

El HTML nativo ya expone roles, comportamiento del teclado y muchos estados. Un botón real es enfocable, se activa con Enter y Space, y participa en formularios. Un div role="button" tabindex="0" que un modelo pegó todavía necesita esos controladores de teclas, un estado presionado o deshabilitado cuando sea relevante, y un nombre accesible. Si se salta alguno de esos, la tecnología asistiva anuncia un botón que no hace nada con Space. La Guía de prácticas de autoría de ARIA (APG) existe para los casos en los que realmente se necesita un widget personalizado; no es una licencia para restilar un div en cada control.

Errores comunes de ARIA en marcado codificado por vibración

- Rol en el elemento incorrecto: role="button" en un a href, o role="link" en un botón que envía un formulario - ARIA decorativo: aria-label que duplica el texto visible y confunde algunas combinaciones de AT - Estado obsoleto: aria-expanded="true" dejado después de que una renderización del cliente alterna un panel - Spam de puntos de referencia: cinco regiones role="navigation" sin nombres, por lo que las listas de saltos se convierten en ruido - Regiones en vivo para vanidad: aria-live="polite" en cada toast para que la página parlotee

La recomendación WAI-ARIA 1.2 describe la ontología de roles y propiedades; úsela cuando deba extenderse más allá de HTML, no como capa predeterminada en cada nodo (WAI-ARIA 1.2).

Rutas del teclado que el generador olvida

El orden de enfoque, el enfoque visible y los enlaces de saltos se pierden en diseños de un solo disparo. El criterio 2.4.7 requiere un indicador de enfoque visible. El criterio 2.4.11 (Enfoque no oscurecido - Mínimo), nuevo en WCAG 2.2, requiere que los encabezados pegajosos, los banners de cookies y los widgets de chat flotantes no oculten completamente el control enfocado. Tabla la página generada de arriba a abajo. Confirme que el orden coincide con el orden de lectura. Confirme que no hay control varado detrás de una superposición. Confirme que el anillo de enfoque cumple con 1.4.11 frente a lo que se sienta detrás de él.

Un breve pase manual de teclado (15 minutos)

- Desconecte el mouse. Abra la página en un perfil limpio. - Tabla desde el chrome del navegador hasta el documento. ¿Hay un enlace de saltos que funcione? - Alcance cada acción principal sin folklore de tecla de flecha que el componente nunca implementó. - Abra y cierre cada modal con Escape. ¿El enfoque regresa al invocador? - Active el encabezado pegajoso y el banner de cookies. ¿Puede ver el control enfocado? - Golpee cada botón de icono con un lector de pantalla (NVDA o VoiceOver). ¿El nombre coincide con la acción?

Ese pase atrapa lo que Lighthouse no atrapará. Las herramientas automatizadas son un filtro inicial; no son un certificado de conformidad. Para la contratación y las herramientas de decisión automatizadas, la guía de EE. UU. también recuerda a los constructores que las características de IA pueden crear riesgos de discriminación por discapacidad si las interfaces excluyen a las personas que utilizan tecnología asistiva (Guía de AI de ADA.gov). La interfaz de usuario del producto no está exenta de esa forma de pensar solo porque un modelo escribió el JSX.

Hacer que la comprobación sobreviva a la regeneración

Debido a que la regeneración elimina los parches manuales, el control duradero parece infraestructura:

- Tokens de diseño con contraste medido, comprobado en una prueba unitaria o plugin de stylelint - Primitivas de componentes (IconButton, TextField) que siempre emiten estilos de nombre y enfoque - Puerta de accesibilidad de CI (axe o equivalente) en solicitudes de extracción, que falla en nombres vacíos y contraste - Restricciones de promedio que prohíben el hex crudo y prohíben el div como botón sin una bandera de excepción explícita - Paso de teclado humano en cada vertical antes de la versión, registrado como un elemento de lista de verificación, no como una vibración

Tratar la marca generada como salida de borrador no confiable. Revisarla de la misma manera que se revisa una solicitud de extracción de un junior que llegó desde un hackathon de fin de semana: asumir nombres faltantes, asumir ARIA teatral, asumir texto pastel.

Criterios de decisión: ¿arreglar en tokens, primitivas o código de página?

Usar este orden cuando llega un informe de error:

- Si muchas páginas comparten el color de texto apagado incorrecto, arreglar el token y volver a medir las razones. - Si un tipo de control carece de nombres (todos los botones de icono), arreglar la primitiva y eliminar los parches locales. - Si un héroe de marketing único falla sobre una foto, arreglar la superposición o el tratamiento de texto de esa página. - Si ARIA se pegó al elemento incorrecto, reemplazar con un control nativo antes de escribir más atributos.

Los parches de ARIA a nivel de página son los menos duraderos. También son los que las sesiones de codificación de vibración aman emitir. Empujar las correcciones hacia arriba.

Qué no es esto

Este artículo no es un certificado de conformidad con WCAG para su producto. No es un asesoramiento legal y no afirma que ejecutar A11yGuard (o cualquier escáner) haga que un sitio sea "compliant con ADA" o "100% accesible". Las comprobaciones automatizadas de contraste y ARIA detectan fallos medibles; no detectan decisiones de juicio sobre el orden de lectura, alternativas de arrastre y si un nombre es comprensible. No inventamos logotipos de clientes, aumentos de conversión o garantías de "nunca perder un error de contraste". El papel honesto del producto es un primer paso rápido más una lista de verificación que todavía posee.

Cierre

Las matemáticas de contraste y los nombres accesibles fallan de forma independiente y se regeneran juntos. Bloquee tokens, prefiera controles nativos, verifique ARIA contra APG cuando deba personalizar y mantenga un pase de teclado en el ritual de lanzamiento. Utilice las referencias a continuación cuando se dispute una afirmación sobre una proporción o un criterio — el texto de la especificación gana sobre la memoria de un modelo de chat.

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