yonathan-boop/Claude - Accesibilidad Humana para Antislop

antislop-human

Anti Slop: Reglas para Agentes de Codificación con IA. Habilidad Humana

Parte del sistema antislop. Léase junto con antislop.md (el núcleo). Esta habilidad profundiza en el factor humano: la UI debe seguir siendo utilizable por personas con diferentes ojos, manos y configuraciones. Contraste, teclado, foco, estados y los detalles móviles que excluyen a las personas.

Cómo usar esta habilidad

• Cargar junto con antislop.md cada vez que la tarea construya o edite UI. El núcleo contiene el mecanismo (la prueba de propósito, los tres niveles, la Puerta de Entrega); esta habilidad contiene la profundidad del lado humano: las partes de una UI que excluyen a personas con diferentes ojos, manos y configuraciones.
• Cada entrada tiene la misma forma: Decir (el patrón), Por qué (a quién excluye y por qué se lee como inacabado), Arreglo (qué hacer en su lugar), con la regla central citada como R-XX.
• La accesibilidad no es una lista de verificación de extras añadidos al final. Es parte de la promesa central de que "la UI se sostiene" (C-4). La Puerta de Entrega del núcleo sigue siendo la puerta; la "Lista de Verificación de Habilidad Humana" al final de este archivo es el suplemento para ejecutar junto a ella.
• El verificador de contraste (fórmula + tabla de referencia + script) reside en esta habilidad. Úsalo para cada par de colores que no puedas verificar a simple vista.
• Esta habilidad conserva solo los detalles móviles que excluyen a las personas: zoom y teclado en pantalla.

Color y Contraste

Texto de Bajo Contraste

• Decir: texto gris claro sobre fondo blanco o casi blanco, texto fino del cuerpo, etiquetas apagadas elegidas porque se ven "elegantes" pero son difíciles de leer.
• Por qué: excluye a usuarios con baja visión y a todos en luz brillante. Es una elección visual hecha sin verificar el estándar, que es exactamente el tipo de valor predeterminado que el filtro existe para detectar.
• Arreglo: cumplir los mínimos WCAG AA (R-25): 4.5:1 para texto normal, 3:1 para texto grande (18px+). Calcula la relación; no la calcules a ojo.

Texto Sobre una Foto o Degradado

• Decir: texto blanco colocado directamente sobre una imagen o degradado que es claro en algunas áreas, verificado solo en un punto brillante.
• Por qué: el contraste es local. Donde la imagen es clara, el texto cae por debajo de 4.5:1 incluso si el héroe "se ve" bien. R-25 requiere probar toda el área que el texto atraviesa, no un solo punto.
• Arreglo: agregar una capa semitransparente o un bloque de color sólido detrás del texto, luego verificar el peor punto, no el mejor. Si alguna parte del área de texto falla, el tratamiento falla.

La Alucinación Gris sobre Gris

• Decir: "gris oscuro sobre negro" o "gris claro sobre blanco" que se afirma que pasa AA sin un cálculo.
• Por qué: esta es la alucinación de accesibilidad más común. El ojo sobreestima el contraste en pares grises, y los agentes repiten la afirmación porque suena plausible. #555555 sobre negro es 2.8:1. Falla.
• Arreglo: nunca afirmar que un par pasa. Ejecutar el verificador de contraste (abajo) o aplicar la fórmula. Cuando ninguno sea posible, usar la tabla de referencia.

Contraste No Textual

• Decir: componentes interactivos (botones, iconos, bordes de entrada, indicadores de foco, segmentos de gráficos) distinguidos de su fondo por menos de 3:1.
• Por qué: la UI no textual transmite información mediante forma y borde. Cuando el borde es un pelo de tinte, los usuarios con baja visión no pueden encontrar el control. El mismo estándar se aplica a estados como hover y seleccionado.
• Arreglo: dar a cada límite de componente y cada indicador de estado una relación de 3:1 contra colores adyacentes (WCAG 1.4.11). Emparejar iconos con una etiqueta de texto que cumpla 4.5:1.

El Verificador de Contraste

El hogar del verificador de contraste. Tres capas, de más a menos conveniente:

El script. Cuando un entorno de script esté disponible y el archivo esté presente, ejecútalo en lugar de calcular a mano. El script se envía en la carpeta de esta habilidad (contrast-check.py, junto a este SKILL.md). Ejecútalo con python3 en macOS y Linux, python en Windows:

python3 "${CLAUDE_SKILL_DIR}/contrast-check.py" "#FFFFFF" "#777777"
# texto normal: FALLA (4.48 < 4.5)
# texto grande:  PASA (4.48 >= 3.0)

Si la variable ${CLAUDE_SKILL_DIR} no está disponible en este agente, apunta la ruta del script directamente a la carpeta de esta habilidad. El script existe para que los agentes dejen de alucinar AA. Toma dos colores hexadecimales e imprime la relación y el veredicto para ambos tamaños de texto. Si el archivo falta, la fórmula y la tabla a continuación son completas por sí mismas. Nunca te bloquees por el script.

La fórmula (WCAG 2.x).

1. Relación de contraste = (L1 + 0.05) / (L2 + 0.05), donde L1 es la luminancia relativa más clara y L2 la más oscura.
2. Luminancia relativa L de un color: convertir cada canal a 0-1 (c = hex / 255), luego linealizar: si c <= 0.03928, c_lin = c / 12.92; de lo contrario c_lin = ((c + 0.055) / 1.055)^2.4.
3. L = 0.2126*R + 0.7152*G + 0.0722*B.
4. Comparar la relación sin redondear: 4.5:1 para texto normal, 3:1 para texto grande (18px+, según R-25). Redondear solo para mostrar, de modo que un par en 4.498:1 imprima como 4.50 y aún así falle 4.5:1. La relación máxima es 21.0 (negro sobre blanco).

La tabla de referencia (pares comunes, calculados con la fórmula):

Par (texto sobre fondo)	Relación	Texto normal (4.5)	Texto grande (3.0)
Negro sobre blanco	21.00	Pasa	Pasa
Blanco sobre negro	21.00	Pasa	Pasa
Blanco sobre #333333	12.63	Pasa	Pasa
Blanco sobre #666666	5.74	Pasa	Pasa
#777777 sobre blanco	4.48	Falla	Pasa
#777777 sobre #070707	4.50	Falla	Pasa
Blanco sobre #888888	3.54	Falla	Pasa
Blanco sobre #999999	2.85	Falla	Falla
#555555 sobre negro	2.82	Falla	Falla

La fila #777777 sobre #070707 es el caso cercano al umbral: 4.4983:1 se redondea a 4.50 para mostrar y aún así falla 4.5:1.

Lee la tabla como una comprobación de cordura, no como un sustituto. Cualquier par no listado, o cualquier cosa cerca de un umbral, pasa por la fórmula o el script.

Teclado

Contorno de Foco Eliminado

• Decir: outline: none o outline: 0 sin un estilo de foco de reemplazo.
• Por qué: los usuarios de teclado no pueden ver dónde están. Es la forma más rápida de hacer una UI inutilizable sin un ratón, y R-32 lo prohíbe directamente.
• Arreglo: mantener o reemplazar el contorno con un estilo :focus-visible visible que cumpla el mismo estándar de contraste (3:1 contra sus vecinos). Nunca establecer outline: none sin un reemplazo.

Patrones Solo para Ratón

• Decir: menús que se abren solo al pasar el ratón, desplegables que se abren al hacer clic pero no se abren con teclado, arrastrar y soltar sin alternativa de teclado.
• Por qué: cada uno excluye a usuarios de teclado y tecnología de asistencia (R-32). Si un control no se puede alcanzar y operar con Tab, Enter o Espacio, no existe para un grupo entero de personas.
• Arreglo: todo elemento interactivo es alcanzable y operable por teclado (R-32): orden de tabulación lógico que sigue el orden visual, activación con Enter o Espacio, y diálogos que se puedan cerrar con Escape (R-26).

Orden de Tabulación Roto

• Decir: el foco salta por la página, se salta contenido o cae en elementos ocultos porque el orden del DOM no coincide con el orden visual.
• Por qué: el orden de tabulación que lee el orden del código en lugar del orden visual hace que la navegación sea impredecible (R-32). Los usuarios pierden su lugar y la página se siente rota.
• Arreglo: mantener el orden del código coincidiendo con el orden visual, agregar enlaces de salto para páginas largas, y nunca dar a contenido real tabindex="-1" a menos que sea parte de una trampa de foco controlada como un diálogo.

Foco y Estados

Indicador de Foco Débil o Invisible

• Decir: un anillo de foco del mismo color que el fondo, un anillo que solo aparece al pasar el ratón, o un indicador más delgado que un borde de 1px.
• Por qué: el indicador de foco es cómo los usuarios de teclado saben dónde están. Si falla el estándar de contraste o solo se muestra al pasar el ratón, el uso solo con teclado se rompe (R-32, R-34).
• Arreglo: un indicador de foco visible en cada elemento interactivo, 3:1 contra colores adyacentes, en cada tema que distribuyas. Verifícalo en modo oscuro y claro.

Retroalimentación Solo por Color

• Decir: éxito, error y estado comunicados solo por color: texto de error rojo, borde de éxito verde, una etiqueta teñida, sin icono, etiqueta o texto.
• Por qué: excluye a usuarios daltónicos y con baja visión, y desaparece por completo en el modo de colores forzados. Un estado que depende de ver un tono no es un estado (C-4).
• Arreglo: emparejar cada señal de color con texto, un icono o un patrón. Los estados de error son texto primero: "La contraseña debe tener al menos 8 caracteres", no solo un borde rojo.

Estados de UI Faltantes

• Decir: una vista de datos sin estado vacío, de carga o de error, o estados que existen pero son invisibles: un spinner sin texto, una pantalla vacía sin explicación.
• Por qué: R-27 requiere los tres estados; el ángulo de accesibilidad es que cada uno debe ser perceptible e informativo, no decorativo. Un spinner de carga sin contexto se lee como una página congelada para los usuarios de lectores de pantalla.
• Arreglo: cada vista de datos tiene los tres estados (R-27), cada uno anunciado o visible: un mensaje vacío explícito, un estado de carga con texto, y un estado de error que diga qué sucedió y cómo proceder.

Zoom y Uso Móvil

La mecánica de diseño detrás de lo móvil (puntos de ruptura, escala, cuadrículas, desbordamiento, objetivos táctiles) es responsabilidad de antislop-layoutmobile. Esta sección conserva solo los detalles móviles que excluyen a las personas: el zoom y el teclado en pantalla.

Texto que No Puede Hacer Zoom

• Decir: tamaños de fuente fijos en píxeles, o contenedores con overflow: hidden que recortan el texto al 200% de zoom.
• Por qué: los usuarios deben poder redimensionar el texto (WCAG 1.4.4). Si hacer zoom al 200% recorta el contenido o fuerza el desplazamiento horizontal, el texto no es redimensionable en la práctica.
• Arreglo: tipografía fluida que se reajuste con el zoom, sin contenedores que recorten el texto, y verificar que el diseño se mantenga al 200% de zoom en una ventana estrecha (R-35).

El Teclado Móvil Cubre el Formulario

• Decir: entradas en la parte inferior de la ventana ocultas detrás del teclado en pantalla, sin desplazamiento a la vista y sin espacio para la entrada.
• Por qué: un formulario que el usuario no puede ver o alcanzar es un formulario que no puede completar. Es una exclusión solo para móviles (R-03).
• Arreglo: cuando una entrada recibe el foco, se desplaza a la vista por encima del teclado, con suficiente relleno inferior para que el campo enfocado nunca quede cubierto. Probar con un dispositivo real o un teclado emulado.

Lista de Verificación de Habilidad Humana

Ejecutar estas junto con la Puerta de Entrega principal cuando la tarea involucre UI. Todas las respuestas deben ser sí:

• ¿Está verificado cada par de texto y fondo contra el verificador de contraste (fórmula, tabla o script), incluido el texto sobre imágenes y degradados? (R-25)
• ¿Cada límite de componente interactivo e indicador de estado cumple 3:1 contra su fondo? (contraste no textual)
• ¿El indicador de foco es visible, de alto contraste y está presente en cada elemento interactivo en todos los temas? (R-32, R-34)
• ¿Cada elemento interactivo es alcanzable y operable por teclado, con diálogos que se puedan cerrar con Escape y sin outline: none sin un reemplazo? (R-32, R-26)
• ¿Los estados vacío, de carga y de error de cada vista de datos están presentes y son perceptibles, no solo por color? (R-27, C-4)
• ¿Se puede redimensionar el texto al 200% sin que sea recortado, y el teclado móvil nunca cubre una entrada enfocada? (R-35)